Subject: Re: [Idr] AD Review of draft-ietf-idr-tunnel-encaps-15

From: Alvaro Retana <[email-masked]>
Date: Sat, 25 Apr 2020 12:45:13 +0000

Ping!

On February 25, 2020 at 12:09:11 PM, Keyur Patel ([email-masked]) wrote:

Thanks for the detail review and comments. We will get back to you soon
with our response.

---

From: Keyur Patel <[email-masked]>
Date: Sat, 25 Apr 2020 14:02:12 +0000

Hi Alvaro,

We are working on your review comments. We will send the reply soon.

Apologies for taking it a bit long.

Regards,
Keyur

On Apr 25, 2020, at 5:45 AM, Alvaro Retana <[email-masked]> wrote:

Ping!

On February 25, 2020 at 12:09:11 PM, Keyur Patel ([email-masked]<mailto:[email-masked]>) wrote:

Thanks for the detail review and comments. We will get back to you soon with our response.

---

From: John Scudder <[email-masked]>
Date: Mon, 27 Apr 2020 20:45:17 +0000

I just noticed this, very late:

On Feb 21, 2020, at 7:47 AM, Alvaro Retana <[email-masked]<mailto:[email-masked]>> wrote:

211    In this document we address these deficiencies by:

[style nit] Please don't write in first person.  Instead: "This
document addresses these deficiencies by:".  There is similar text in
other places.

FWIW I disagree with this completely and will gladly fight you about it, name the place and the weapon.

I joke about fighting of course, but not about disagreeing. My thesis advisor tried to knock it into my head that it’s not actually a requirement that academic writing be boring. I usually fail at this but I appreciate it when people try!

That said, if the authors want to make the change, it’s fine of course. “Nobody ever got fired for avoiding the first person.” (Or writing in the passive voice for that matter.)

—John

---

From: Alvaro Retana <[email-masked]>
Date: Mon, 27 Apr 2020 21:09:20 +0000

Hi!

It’s just a style nit, so nothing I’m going to dig out my sword for — I’m
assuming an old fashion duel, of course. ;-)

Seriously, it’s just a nit.  Personally, I don’t like first person because
it is usually associated with the point of view of the authors, and IETF
documents should reflect the point of view of the WG…

Alvaro.

On April 27, 2020 at 4:45:20 PM, John Scudder ([email-masked]) wrote:

On Feb 21, 2020, at 7:47 AM <http://airmail.calendar/2020-02-21 07:47:00
EST>, Alvaro Retana <[email-masked]> wrote:

FWIW I disagree with this completely and will gladly fight you about it,
name the place and the weapon.

I joke about fighting of course, but not about disagreeing. My thesis
advisor tried to knock it into my head that it’s not actually a requirement
that academic writing be boring. I usually fail at this but I appreciate it
when people try!

That said, if the authors want to make the change, it’s fine of course.
“Nobody ever got fired for avoiding the first person.” (Or writing in the
passive voice for that matter.)

---

From: John Scudder <[email-masked]>
Date: Mon, 27 Apr 2020 21:21:02 +0000

Hi Alvaro,

Regarding obsoleting other work, it makes sense to me that work that becomes de-facto obsolete as a result of 5512 being obsoleted, should also be obsoleted. Just seems like good document hygiene.

I assume that does NOT imply that this document would need to provide replacements for the obsoleted specifications. As you say below, that’s a different track of work and can be pursued independently. We’re just talking about adding two more document numbers to the Obsoletes header, right?

Thanks,

—John

(1) Obsoleting other work

This document deprecates the Encapsulation SAFI because it "has never
been used in production".  What about other work that specifies the
use of the Encapsulation SAFI?  Should they also be Obsoleted by this
document?  [Yes, I know there was a long discussion on the list, which
resulted in the text in §1.4.]

Both rfc5566 (mentioned in §1.4) and rfc5640 specify the use of the
Encapsulation SAFI.  Is there interest in Updating those RFCs?  If
not, then it seems like the easy thing to do is to Obsolete that work
with this document.  If there is, then I agree with the text in §1.4
in that the effort would be out of scope of this document.  In either
case, I think that §1.4 raises more questions than it answers and is
not needed in this document.

John: As Shepherd, can you please ping the WG (you may have to reach
out to bess as well) about potential interest in Updating
rfc5566/rfc5640.  I won't hold this document waiting for the
resolution, but having an idea of any interest would be nice.
Interest has been expressed for rfc5566bis [1], but didn't see
anything related to rfc5640.  BTW, the mailing list contains
discussion about other IPsec-related drafts that use tunnel-encap; I'm
not sure of their relationship (if any) to rfc5566.

---

From: Alvaro Retana <[email-masked]>
Date: Mon, 27 Apr 2020 21:38:35 +0000

On April 27, 2020 at 5:21:04 PM, John Scudder wrote:

John:

Hi!

> Regarding obsoleting other work, it makes sense to me that work that becomes
> de-facto obsolete as a result of 5512 being obsoleted, should also be
> obsoleted. Just seems like good document hygiene.
>
> I assume that does NOT imply that this document would need to provide
> replacements for the obsoleted specifications. As you say below, that’s a
> different track of work and can be pursued independently. We’re just talking
> about adding two more document numbers to the Obsoletes header, right?

Yes, correct -- and a sentence to the Abstract/Introduction.

I think that the decision to add those documents, or not, depends on
whether the effort to Update them (if there is interest) starts soon
or not (soon = by the time this document gets to IESG Evaluation).  As
it stands now (I haven't found rfc5566bis or rfc5640bis), and unless
there's explicit interest in starting work soon on *bis, it seem like
Obsoleting is the right answer.

Alvaro.

> > On Feb 21, 2020, at 7:47 AM, Alvaro Retana wrote: