MIME-Version: 1.0
References: 
 <CAF4+nEHKZuaX9oCjbXusep4uUd=weaJXTFpfXcog-A4h04ETXA@mail.gmail.com>
 <2FC6578F-B536-451E-950B-787B359F82CD@deployingradius.com>
In-Reply-To: <2FC6578F-B536-451E-950B-787B359F82CD@deployingradius.com>
From: Donald Eastlake <d3e3e3@gmail.com>
Date: Mon, 18 Aug 2025 16:56:13 -0400
Message-ID: 
 <CAF4+nEEpBB+AVAEnRkAtm63T-JwTezUNfrxf7mVzyweGg9PepA@mail.gmail.com>
To: Alan DeKok <aland@deployingradius.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Message-ID-Hash: 2YKLWCXY3YURCKYRUPQJHQTCV2FBHRLM
CC: "iesg@ietf.org" <iesg@ietf.org>, secdir <secdir@ietf.org>,
 draft-ietf-radext-reverse-coa.all@ietf.org
Precedence: list
Subject: =?utf-8?q?=5Bsecdir=5D_Re=3A_SECDIR_review_of_draft-ietf-radext-reverse-coa?=
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/secdir/7jRJeDhfSDNCxflruk87W5I0MoQ>

Hi Alan,

I am satisfied with your changes and consider my comments resolved.

Thanks,
Donald
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 d3e3e3@gmail.com

On Sun, Aug 17, 2025 at 5:38=E2=80=AFPM Alan DeKok <aland@deployingradius.c=
om> wrote:
>
> On Aug 6, 2025, at 6:13=E2=80=AFPM, Donald Eastlake <d3e3e3@gmail.com> wr=
ote:
> > Security
> > --------
> >
> > The Security Considerations Section 8 just says (in different words)
> > that the document improves security by standardizing reverse paths for
> > CoA-Request and Disconnect-Request packets. I would add a little bit
> > about why, if there is a need to disconnect or change authentication,
> > it can be a security problem if you cannot do that.
>
>   Done.
>
> > Also, Section 4
> > just says that in various cases of misconfiguration CoA (which is
> > defined to also include Disconnect in this document) packets will not
> > flow and says this causes no further issues. I suggest "there will be
> > no other issues with this misconfiguration" -> "which may reduce
> > security (see Section 8)".
>
>    Done.
>
> > Nits / trivial issues
> > ---------------------
> >
> > Section 1, 2nd and 3rd paragraphs: Perhaps these should be merged or
> > something as on initial reading it was not clear to me that the
> > "Section 3.4" in the 3rd paragraph was that section in RFC 6614 which
> > is referenced in the 2nd paragraph.
>
>   I've reworded the introduction to make it clearer.
>
> > Section 1, 3rd paragraph: Should "which types of packets are supported
> > on a server" be "which types of packets it supports"?
>
>   That's a quote from another specification, so I'll leave it alone, and =
make it clearer that it's a quote.
>
> > Section 3: "a configuration and signalling," -> "a configuration and
> > signalling method,"
>
>   Done.
>
> > Section 3 says there are two additions. These are then discussed in
> > Section 4 and 5 but there is no tie between those sections and Section
> > 3. Suggest adding at the end of Section 3: "These additions are
> > discussed in Sections 4 and 5 respectively."
>
>   Done.
>
> > Section 5.1, 2nd paragraph: "have the choice more than one" -> "have a
> > choice of more than one"
>
>   Fixed.
>
> > Section 5.2, 2nd paragraph: the server's connection choice is not
> > unconstrained. "chooses one connection" -> "chooses one of these
> > connections"
>
>   Fixed.
>
> > Section 6.3, I didn't review Section 6 very closely but it seems odd
> > that in Section 6.3 there is a raw direct reference rather than
> > indirecting through the Informational References section. But, since
> > Section 6 is going away, it does not matter much.
>
>   OK.