Subject: Re: [Roll] Benjamin Kaduk's No Objection on draft-ietf-roll-useofrplinfo-29: (with COMMENT)

From: Ines Robles <[email-masked]>
Date: Tue, 25 Jun 2019 18:15:35 +0300

Hi Benjamin,

Many thanks for your new review, we believe that version 30 addresses your
concerns. Please find comments in-line

On Mon, May 27, 2019 at 7:27 AM Benjamin Kaduk via Datatracker <
[email-masked]> wrote:

> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Thank you for addressing my Discuss (and Comment) points!
>
> I just have a few more minor notes on the -29:
>
> the "(1)" footnote is no longer present.
>

<author>

Yes, it was deleted. Because the field in the table  was “No” before
(version 25), so we put the footnote to indicate that for 6tisch could be
relevant. but since we made RPI mandatory, it is a yes, so no need the
footnote. Anyway we mention the relevance of this case for 6tisch networks.
We added the explanation in the text.

“In the Figure the (1) indicates a 6tisch case [RFC8180
<https://tools.ietf.org/html/rfc8180>],

   where the RPI header may still be needed for the instanceID to be

   available for priority/channel selection at each hop”

</author>

>
> I'm also not sure about the global change from "<foo>_i are the
> intermediate routers" to "<foo>_i is the intermediate router", since the
> general case can still have more than one intermediate in each
> direction.  But perhaps we should leave this to the RFC Editor.
>

<author>

We changed back to “are the intermediate routers”. Yes Editor can confirm
that.

</author>

>
> Section 11
>
> nit: "especially if the target of the attack is targeting another LLN"
> had redudant "target" added -- just "especially if attack is targeting
> another LLN" would be fine.
>

<author>

Fixed, thank you

</author>

>
> I think the claim that "[i]n the end, the IPsec tunnels would be
> providing only BCP38-like origin authentication!" could use some
> additional justifcation.
>
> <author> answered it in a previous email </author>

Thank you very much,

Ines, Michael and Pascal

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 25 Jun 2019 10:45:38 -0500

> We added the explanation in the text.

I am not 100% sure, but I think I was just noting that Figure 14 still had
"(1)" in the RPI column for one row, that may have been an editorial
oversight.

Thanks for all the updates!

-Ben

---

From: Ines Robles <[email-masked]>
Date: Tue, 25 Jun 2019 18:48:49 +0300

Hi Benjamin,

Thank you very much. Yes, you are correct. we left the (1) to indicate the
6tisch case.

Cheers,

Ines

---

From: Alvaro Retana <[email-masked]>
Date: Tue, 25 Jun 2019 19:39:28 +0200

On June 25, 2019 at 11:49:02 AM, Ines Robles ([email-masked])
wrote:

Ines:

Hi!

There’s another “(1)” in the new text in §6: "Because of (1), packets from
the Internet have to be encapsulated.”   I think this is the last nit — we
can take care of it while at the RFC Editor, no need for another revision.

Thanks!

Alvaro.

---

From: Ines Robles <[email-masked]>
Date: Tue, 25 Jun 2019 20:43:40 +0300

Hi Alvaro,

Thank you very much for let us know, Yes. you are right.  Ok, we will let
us know to the RFC Editor.

Best wishes,

Ines.

On Tue, Jun 25, 2019 at 8:39 PM Alvaro Retana <[email-masked]>
wrote:

> On June 25, 2019 at 11:49:02 AM, Ines Robles (
> [email-masked]) wrote:
>
> Ines:
>
> Hi!
>