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] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-i2rs-protocol-security-requirements-06=3A_=28with_COMMENT?= =?utf-8?q?=29?=
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>om>:
> >
> > 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>om>:
> >>
> >> 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
> >>
> >
> >
>
>