Re: [mile] [Technical Errata Reported] RFC6545 (5588)
Logan Widick <logan.widick@gmail.com> Mon, 28 January 2019 00:21 UTC
Return-Path: <logan.widick@gmail.com>
X-Original-To: mile@ietfa.amsl.com
Delivered-To: mile@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 135C7128766 for <mile@ietfa.amsl.com>; Sun, 27 Jan 2019 16:21:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 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, URIBL_BLOCKED=0.001] 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 N8K14V4WWUON for <mile@ietfa.amsl.com>; Sun, 27 Jan 2019 16:21:36 -0800 (PST)
Received: from mail-it1-x12e.google.com (mail-it1-x12e.google.com [IPv6:2607:f8b0:4864:20::12e]) (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 7016A130EB0 for <mile@ietf.org>; Sun, 27 Jan 2019 16:21:36 -0800 (PST)
Received: by mail-it1-x12e.google.com with SMTP id g85so18221250ita.3 for <mile@ietf.org>; Sun, 27 Jan 2019 16:21:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=xH7iq+XjlcU3E7+nj+1uSp7cfXPnfR5gRIGNBksiAXg=; b=mFtIbaq0BBmJQEp5Qb3ARdZ7UXAGnrU+3jLMSbuFqKFRZvcPd7BS7MTEJSw8zX/5Ft /xsmrEl5+p0zjm+LHur9DJ2XfAZkv37a6irbCL6smYbWG9BDH1jVozZtHLRIHYpygevZ WvJ0hy3ET32wavSM4wvOOh7jvFYfXrK+vhFwhgIVdrPqRngw5OIhwOqU4dl8zMh24oUP agxnxqwIk1KMkEuH8MljVl5Bh4bIf5gLPRSGZsDYkwUE1bNd8ncjqZhIqUCIpvM8Ilcu tMf5sJxKKGClt9p3d7DjxraJOAQYjaIp2RcnTE4VYrzkaEdJGWDokC7hOWChekDg4VEO j6VA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=xH7iq+XjlcU3E7+nj+1uSp7cfXPnfR5gRIGNBksiAXg=; b=O9ZPMmmaIijfSVLlXZ1WMVrU37ooUOQR6zI1RuT54vksW/kOEbco1hK9UeIVFiuTPb 1InkCXpWpvgRy6L0mYagR0cxdGKZ8v4i4slDKE9Zz+BjcaMVx6YqGojOyK99AFON3NMP i7rJWELd4DCQrLBoRpnYOxyirwamlRqL3BnrxjDpICcBAGaqr4spBRjw84e16ywYgLqe t/Cwna1VX8TLBISfROYZDmzrAtrK47DJLcUIohZmq4xXzlJ7iumyyRHTUzZ8+7V/1h+9 Xi0/q9mz7OaCi41sBFhY/TU8SEd0eGtx2fNQblWJrsA3THxpGW4GIrAIkEM3QfXvvu/b iqzw==
X-Gm-Message-State: AJcUukeCpNUx/5XbvcjGuTKaoneAO3Hv4FP4NsvSwT+yyGi12LFmzxiC Ik9ZJoPcczmPIj149/zdSGokEI37y322CMzqQ10=
X-Google-Smtp-Source: ALg8bN6SRI2KcimG4Bodl4wODn6VwRvZl6m6cN8QSeSAlVlMo4XCnmem9H8qewPy7siMwnobza//OkOgQP36Q594FHM=
X-Received: by 2002:a24:f30b:: with SMTP id t11mr7831313ith.40.1548634895507; Sun, 27 Jan 2019 16:21:35 -0800 (PST)
MIME-Version: 1.0
References: <20181228190203.16C81B81E04@rfc-editor.org> <E8CEA61867EF1E4A9BD05D64D74F76B23AC019B2@MX307CL02.corp.emc.com> <20190128000040.GP49072@kduck.mit.edu>
In-Reply-To: <20190128000040.GP49072@kduck.mit.edu>
From: Logan Widick <logan.widick@gmail.com>
Date: Sun, 27 Jan 2019 18:21:23 -0600
Message-ID: <CAMmAzE+MXTxiAsRkP94c9z_830gzSP-tPanUh2tc7sPypc7xkw@mail.gmail.com>
To: Benjamin Kaduk <kaduk@mit.edu>
Cc: "Moriarty, Kathleen" <Kathleen.Moriarty@dell.com>, RFC Errata System <rfc-editor@rfc-editor.org>, "ekr@rtfm.com" <ekr@rtfm.com>, "ncamwing@cisco.com" <ncamwing@cisco.com>, "takeshi_takahashi@nict.go.jp" <takeshi_takahashi@nict.go.jp>, "mile@ietf.org" <mile@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000d56901058079a8a6"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mile/lyokLV7AaTprW69ooNQnIdS0kmI>
Subject: Re: [mile] [Technical Errata Reported] RFC6545 (5588)
X-BeenThere: mile@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" <mile.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mile>, <mailto:mile-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mile/>
List-Post: <mailto:mile@ietf.org>
List-Help: <mailto:mile-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mile>, <mailto:mile-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 28 Jan 2019 00:21:40 -0000
Just submitted a separate report for the TrafficType issue. Sincerely, Logan Widick On Sun, Jan 27, 2019, 18:00 Benjamin Kaduk <kaduk@mit.edu wrote: > I am going to approve this erratum but remove the note about "perhaps a > better revision" that would result in an actual protocol change. > > Can one of you please file the corresponding errata report for the "similar > issue [that] is also present with the way that the TrafficType is defined > on pages 19-20"? > > Thanks, > > Benjamin > > On Wed, Jan 02, 2019 at 04:13:11PM +0000, Moriarty, Kathleen wrote: > > Logan, > > > > Thank you very much for your review and submitting an errata. The > change makes sense and the schema is considered normative over the text. > Since the schema is normative and that agrees with what you are saying for > the text, I think approving this errata makes sense as editorial and either > verified or hold for document update should work. > > > > Are there any other opinions? > > > > Thank you, > > Kathleen > > > > -----Original Message----- > > From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] > > Sent: Friday, December 28, 2018 2:02 PM > > To: Moriarty, Kathleen; kaduk@mit.edu; ekr@rtfm.com; ncamwing@cisco.com; > takeshi_takahashi@nict.go.jp > > Cc: logan.widick@gmail.com; mile@ietf.org; rfc-editor@rfc-editor.org > > Subject: [Technical Errata Reported] RFC6545 (5588) > > > > > > [EXTERNAL EMAIL] > > > > The following errata report has been submitted for RFC6545, > > "Real-time Inter-network Defense (RID)". > > > > -------------------------------------- > > You may review the report below and at: > > http://www.rfc-editor.org/errata/eid5588 > > > > -------------------------------------- > > Type: Technical > > Reported by: Logan Widick <logan.widick@gmail.com> > > > > Section: 5.1 > > > > Original Text > > ------------- > > Page 18 says: > > > > PolicyRegion > > > > One or many. REQUIRED. The values for the attribute "region" are > > used to determine what policy area may require consideration > > before a trace can be approved. The PolicyRegion may include > > multiple selections from the attribute list in order to fit all > > possible policy considerations when crossing regions, consortiums, > > or networks. > > > > region > > > > One or many. REQUIRED. ENUM. The attribute region is used to > > identify the expected sharing range of the incident information. > > The region may be within a region or defined by existing > > relationships such as those of a consortium or a client to a > > service provider. > > > > Corrected Text > > -------------- > > Page 18 should say: > > > > PolicyRegion > > > > One or many. REQUIRED. The values for the attribute "region" are > > used to determine what policy area may require consideration > > before a trace can be approved. The PolicyRegion may include > > multiple selections from the attribute list in order to fit all > > possible policy considerations when crossing regions, consortiums, > > or networks. > > > > region > > > > One. REQUIRED. ENUM. The attribute region is used to > > identify the expected sharing range of the incident information. > > The region may be within a region or defined by existing > > relationships such as those of a consortium or a client to a > > service provider. > > > > Notes > > ----- > > The text as written (with "One or many" instances of the "region" > attribute) suggests that > > <PolicyRegion region="ClientToSP" region="SPToClient"/> > > would be legal. > > > > However, the schema (Section 8) and the fact that a single XML tag can't > contain more than one instance of a given attribute (see > https://www.w3.org/TR/xml/#uniqattspec, "An attribute name MUST NOT > appear more than once in the same start-tag or empty-element tag") indicate > that the above example of a PolicyRegion is not legal, and would need to be > replaced with: > > <PolicyRegion region="ClientToSP"/> > > <PolicyRegion region="SPToClient"/> > > > > Perhaps a better revision might be to put PolicyRegion as its own class, > complete with its own (sub-)section and UML diagram, much like the > IncidentID class in IODEF. That would make things more clear. > > > > A similar issue is also present with the way that the TrafficType is > defined on pages 19-20. > > > > Instructions: > > ------------- > > This erratum is currently posted as "Reported". If necessary, please > > use "Reply All" to discuss whether it should be verified or > > rejected. When a decision is reached, the verifying party > > can log in to change the status and edit the report, if necessary. > > > > -------------------------------------- > > RFC6545 (draft-ietf-mile-rfc6045-bis-11) > > -------------------------------------- > > Title : Real-time Inter-network Defense (RID) > > Publication Date : April 2012 > > Author(s) : K. Moriarty > > Category : PROPOSED STANDARD > > Source : Managed Incident Lightweight Exchange > > Area : Security > > Stream : IETF > > Verifying Party : IESG >
- [mile] [Technical Errata Reported] RFC6545 (5588) RFC Errata System
- Re: [mile] [Technical Errata Reported] RFC6545 (5… Moriarty, Kathleen
- Re: [mile] [Technical Errata Reported] RFC6545 (5… Benjamin Kaduk
- Re: [mile] [Technical Errata Reported] RFC6545 (5… Logan Widick