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
>