Re: [i2rs] Mirja Kühlewind's No Objection on draft-ietf-i2rs-protocol-security-requirements-06: (with COMMENT)
Alia Atlas <akatlas@gmail.com> Fri, 19 August 2016 20:11 UTC
Return-Path: <akatlas@gmail.com>
X-Original-To: i2rs@ietfa.amsl.com
Delivered-To: i2rs@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C22B212B047; Fri, 19 Aug 2016 13:11:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.999
X-Spam-Level:
X-Spam-Status: No, score=-101.999 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_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 OMwNG3mQEIsE; Fri, 19 Aug 2016 13:11:14 -0700 (PDT)
Received: from mail-ua0-x233.google.com (mail-ua0-x233.google.com [IPv6:2607:f8b0:400c:c08::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30DE612D144; Fri, 19 Aug 2016 13:02:39 -0700 (PDT)
Received: by mail-ua0-x233.google.com with SMTP id k90so98260013uak.1; Fri, 19 Aug 2016 13:02:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+2JTS6tjaowr0Eukk+5uhOoRQS+XQE+H+XAhYkgCMOY=; b=qKp0elOmobnfe+lBAf3dESgEj3IpksWFHp61uDpYQejDoDp0CEXrEdr7bg8kWk6AgP PFEDP98dosa+r1zxEYBOx9zdH6U/gTz1OHbtM9XwqbiWXiBsvl0wHt8R92q/Yd0wu5jR s7xS5T1FvfE8cnTBSONlJXImy2L13H3d+5AX1PuO1/jQEs6Xnk+jTt+jSvbP5vM+ShbZ 9XVoYuQHLokQg+wu1DBtzfVz+vg0KIHVIk8/xdFruZlt2SSmkeVmaHs5Q17XX+6A7Dw1 qdKr6I4h0GxGJ2UWbf5cLNLx4tbtBvxRRgM31BjAihM2kXLf0KjBXNspvK2UUxhPVguf g1yw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=+2JTS6tjaowr0Eukk+5uhOoRQS+XQE+H+XAhYkgCMOY=; b=Yes9HJERMqJAIfiKyh4ycxEH+/04kmjGkMzxX+ZzhM2CYPuMCg8Bha/I7BYGayxIkk 41jvJN/ZVsloHbabsDW6ug20lg3z66hwzYBX/BudDksPThlAFZ932d1rKR9U/BfRC38e J4B3vwirshYmFvC/OzhRqpOksFGRvIrI6oulerrmuqYQ1fDJnZJii/D2nBkA6RVbELyu lOtrEQdTJgpmhqDHhSWr00W5LwvKxFcbXKNWIqUL0zm4hzIccDIW6mT5eGh7bmWf1MEb xM1tpO+ErLdlCwuFvog2dTjlReozOeMbCmkRiQxz0q8n/Himj660wgCdaw7FI5MccJQg jsRw==
X-Gm-Message-State: AEkoousRzGCF21JBQKc8mTeVcJlLue9TG9dkXNTMcctp4NFt7AASTQlwTac5DRxA62LguFLr6znHLpDlEERxsA==
X-Received: by 10.176.65.40 with SMTP id j37mr4200404uad.116.1471636958198; Fri, 19 Aug 2016 13:02:38 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.50.7 with HTTP; Fri, 19 Aug 2016 13:02:37 -0700 (PDT)
In-Reply-To: <33A86029-D3D3-4BD6-9B48-2273F2632673@kuehlewind.net>
References: <147142304704.12189.4149817417200297360.idtracker@ietfa.amsl.com> <00c001d1f8e5$b5d94790$218bd6b0$@ndzh.com> <D10CA079-8934-4FCB-8006-20ECB04D196D@kuehlewind.net> <013701d1fa45$b58980f0$209c82d0$@ndzh.com> <33A86029-D3D3-4BD6-9B48-2273F2632673@kuehlewind.net>
From: Alia Atlas <akatlas@gmail.com>
Date: Fri, 19 Aug 2016 16:02:37 -0400
Message-ID: <CAG4d1rfmqeAebVJUW5Yv_GpmC8_TvAZMf4Yk7uJZAh2dDqU2xA@mail.gmail.com>
To: "Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net>
Content-Type: multipart/alternative; boundary="94eb2c122a9a21c225053a722e8f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/i2rs/5kB0YqVeQ-fyJuGKufVsPEhChUM>
Cc: "i2rs@ietf.org" <i2rs@ietf.org>, i2rs-chairs@ietf.org, The IESG <iesg@ietf.org>, Jeffrey Haas <jhaas@pfrc.org>, Susan Hares <shares@ndzh.com>, draft-ietf-i2rs-protocol-security-requirements@ietf.org
Subject: Re: [i2rs] Mirja Kühlewind's No Objection on draft-ietf-i2rs-protocol-security-requirements-06: (with COMMENT)
X-BeenThere: i2rs@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Interface to The Internet Routing System \(IRS\)" <i2rs.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/i2rs>, <mailto:i2rs-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/i2rs/>
List-Post: <mailto:i2rs@ietf.org>
List-Help: <mailto:i2rs-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/i2rs>, <mailto:i2rs-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 19 Aug 2016 20:11:27 -0000
Hi Mirja, On Fri, Aug 19, 2016 at 2:54 PM, Mirja Kuehlewind (IETF) < ietf@kuehlewind.net> wrote: > Hi Sue, > > thanks for addressing my comments! > > The only remaining one is if this doc should be published as an own RFC or > merged with the other requirement documents. I mainly wanted to raise this > point for discussion and will leave the decision to the responsible AD. It needs to progress on its own. Thanks, Alia > Mirja > > > > Am 19.08.2016 um 20:15 schrieb Susan Hares <shares@ndzh.com>: > > > > Mirja: > > > > Thank you for your reply. I have removed the text regarding RFC4949. I > believe version-08.txt resolves these comments. > > > > Sue > > > > -----Original Message----- > > From: Mirja Kuehlewind (IETF) [mailto:ietf@kuehlewind.net] > > Sent: Friday, August 19, 2016 1:30 PM > > To: Susan Hares > > Cc: The IESG; jhaas@pfrc.org; i2rs@ietf.org; i2rs-chairs@ietf.org; > draft-ietf-i2rs-protocol-security-requirements@ietf.org > > Subject: Re: [i2rs] Mirja Kühlewind's No Objection on > draft-ietf-i2rs-protocol-security-requirements-06: (with COMMENT) > > > > Hi Sue, > > > > thanks for you replies and background information. Please see further > below. > > > > Mirja > > > >> Am 18.08.2016 um 02:15 schrieb Susan Hares <shares@ndzh.com>: > >> > >> Mirja: > >> > >> Thank you for the review. Please see the comments below. Your > comments are sensible, but the sections were put in place to provide > background for the multiple working groups utilizing these requirements. > Please let me know if I can answer additional questions. > >> > >> Sue Hares > >> > >> -----Original Message----- > >> From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Mirja Kuehlewind > >> Sent: Wednesday, August 17, 2016 4:37 AM > >> To: The IESG > >> Cc: jhaas@pfrc.org; i2rs@ietf.org; i2rs-chairs@ietf.org; > draft-ietf-i2rs-protocol-security-requirements@ietf.org > >> Subject: [i2rs] Mirja Kühlewind's No Objection on > draft-ietf-i2rs-protocol-security-requirements-06: (with COMMENT) > >> > >> Mirja Kühlewind has entered the following ballot position for > >> draft-ietf-i2rs-protocol-security-requirements-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-i2rs-protocol- > security-requirements/ > >> > >> > >> > >> ---------------------------------------------------------------------- > >> COMMENT: > >>> ---------------------------------------------------------------------- > >>> > >>> A few comments: > >>> > >>> 1) I don't think copy&paste from RFC4949 is necessary. I would > recommend to remove this part and just name the definitions that are needed. > >>> > >>> Sue: Initially, the WG and the authors ran into problems with security > words. We included definitions that seem to resolve issues for the WG and > those who will need to >implemented in NETCONF/RESTCONF. > > > >> I understand that this helped the writing process and discussion in the > working group. However, I still advise to remove this from the final RFC > given that readers can easily >check the referred RFC if needed and this > avoids text duplications (which e.g. makes updates very hard). > > > > Sue: I removed the RFC4949 cut and paste in version -08.txt. Can I > consider this item closed? > > > >>> > >>> 2) The following sentence seems to indicate that the refernce to > RFC4949 should be normative. > >>> "The transfer of data via the I2RS protocol has the property of data > integrity described in [RFC4949]." > >>> As I don't think this is needed, I would recommend to rather spell out > the properties here in this sentence. Also, to be honstest I not sure what > this sentence tells me at all. > >>> So maybe stating clearing what you mean (instead of just having the > reference) would help anyway. > >>> > >>> Sue: I have moved RFC4949 to normative. RFC4949 states data > integrity means: a) data has not been changed, destroyed or lost in an > unauthorized (or accidental) manner, > >>> and b) the information has not been modified or destroyed in an > unauthorized manner. This statement covers man-in-the middle attacks or > unauthorized changes. > > > >> Okay. I would still recommend to spell this simply out in the draft > instead of just giving the reference. > > > > Sue: I removed this text. > > > >>> 3) To me it's not really clear why there are several requirments docs > (that also are connected and refer each other; see e.g. section 3.6 and > SEC-REQ-16). > >> The actually context of this doc is only 4 pages (3.1-3.6). Couldn't > those docs be combined to one requirements doc? > >> > >> Sue: This is a good process question for a re-use protocol. A re-use > protocol has a different process than a protocol created out of a single WG. > >> > >>> I2RS broke the requirements into pieces so that as we got agreement on > one piece, the NETCONF/RESTCONF team could begin to work on that piece. > >>> For example, the pub/sub requirements (RFC7923) is already being > worked on in NETCONF. > >>> The I2RS ephemeral state requirements have been delayed by the > NETMOD/NETCONF discussions on opstate. > >>> If the IESG wishes, after we have completed this work, we can compile > these requirements into a single document. > >>> This process focuses on running code and rough consensus rather than a > single review process for the IESG. > > > >> Thanks that's very useful background information. However, even though > I’m happy to hear that this process worked well, the question for > >> final publication in one or multiple RFCs is if there is a benefit for > the final reading audience. > >> Given that these docs are rather short so could be well structured in > one RFC and have interdependencies I don’t see this benefit. > >> I’d rather would assume that a reader would anyway need to look at > multiple docs in any case which would suggest to have one doc. > > > > This is a non-normative section: > > > > Perhaps I was unclear. The final reading audience includes the > following: NETCONF WG, NETMOD WG, vendors, prototype implementers, and > operators. > > The final audience review begins as soon as you approve it. The > NETCONF/NETMOD WG will not consider it real until it is an RFC. > > In a re-use protocol, we can begin work as soon as you approve the > requirements. > > > >>> Given that these docs are rather short so could be well structured in > one RFC and have interdependencies I don’t see this benefit. > >>> I’d rather would assume that a reader would anyway need to look at > multiple docs in any case which would suggest to have one doc. > > > >> As you’ve been mention the IESG review process, I’d like to comment on > this. There is some discussion in the IESG about how to treat different > documents differently as they > >> might need a different level of review (and consensus). However, from > my perspective the main goal is to speed up the publication process. For me > the workload is basically the > same no matter if I read 3 drafts with 15 > pages each or 1 draft with 45 pages. So with respective to this discuss the > question for me would rather be if this doc > >> must be published at RFC at all: Does a document provide valuable > information for future readers or is it just a documentation of the wig’s > working process? > >> We in the IESG didn’t conclude this discussion and therefore I did not > and am not intending to ask this question regarding this document. > > > > This is a meta-question on IESG process. And off-topic to the review of > the document. In your consider of the solution, I think you need to > reconsider the re-use protocols as different than other protocols. This > document must be published as an RFC or we cannot get NETCONF/NETMOD WG to > expand their protocols to include I2RS Features. > > The Pub/SUB work in NETCONF/RESTCONF needs these requirements finalizer > to make progress. Fast approval of the requirements for a re-use protocol > is critical to the WG trying to re-use a protocol. > > > >> 4) Section 3.1 says: > >> "The I2RS architecture [I-D.ietf-i2rs-architecture] sets the following > requirements:" > >> Why is this needed is RFC7921 already sets these requirements? > >> > >> Sue: What a logical and rational statement, but unfortunately this > assumption ran into problems in the working groups (NETMOD/NETCONF) who > reviewed the requirements. >Therefore, this section is there to provide > explicit definitions that resolved inter-group (I2RS to NETCONF and I2RS to > NETMOD) questions on lists. > >> _____________________________________________ > >> i2rs mailing list > >> i2rs@ietf.org > >> https://www.ietf.org/mailman/listinfo/i2rs > >> > > > > > >
- Re: [i2rs] Mirja Kühlewind's No Objection on draf… Mirja Kuehlewind (IETF)
- Re: [i2rs] Mirja Kühlewind's No Objection on draf… Susan Hares
- Re: [i2rs] Mirja Kühlewind's No Objection on draf… Mirja Kuehlewind (IETF)
- Re: [i2rs] Mirja Kühlewind's No Objection on draf… Susan Hares
- [i2rs] Mirja Kühlewind's No Objection on draft-ie… Mirja Kuehlewind
- Re: [i2rs] Mirja Kühlewind's No Objection on draf… Susan Hares
- Re: [i2rs] Mirja Kühlewind's No Objection on draf… Alia Atlas