Subject: [OPSEC] Éric Vyncke's No Objection on draft-ietf-opsec-urpf-improvements-03: (with COMMENT)

From: Éric Vyncke via Datatracker <[email-masked]>
Date: Wed, 21 Aug 2019 07:24:36 -0700

Éric Vyncke has entered the following ballot position for
draft-ietf-opsec-urpf-improvements-03: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-opsec-urpf-improvements/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you for the hard work put into this extensive document which is usually
well-written and easy to understand.

Sriram, also please to see this document completing its path after starting in
OPSEC years ago ;-)

Nevertheless, I have a couple of easy-to-fix COMMENTs and NITs.

Regards,

-éric

== COMMENTS ==

-- Abstract --
The abstract reads like 'promises' but not as a summary of the document. Is
there any chance to add 2 lines summarizing the 'how' ?

-- Section 1.1 --
I am sure that by now you know that you have to use RFC 8174 boilerplate ;-)

-- Section 2.2 --
For completeness and symmetry with section 2.3, please explain which packets
will be dropped.

-- Section 2.3 --
Suggestion: define "RPF list" before first use (even if mostly obvious).

Please define "lateral peer" and why it is different to any other "peer".

-- Section 3.1 --
Please define the "cone" used in this section. First time that I ever read this
term and the RIPE paper does not explain it either (of course I am not a
routing expert).

== NITS ==

-- Section 1 --
Beside the intro, this section also introduces some terminology wording. May I
suggest to have a (sub)section about "terminology" ?

-- Section 2.1 --
CMTS was introduced as an acronym but not DSLAM.

---

From: "Sriram, Kotikalapudi (Fed)" <[email-masked]>
Date: Sat, 31 Aug 2019 04:46:13 +0000

Eric,

Thank you for your comments. Sorry about the delay in replying.
We have uploaded a new version and have included changes
reflecting your comments. Please see:
https://tools.ietf.org/rfcdiff?url2=draft-ietf-opsec-urpf-improvements-04.txt  
Please also see responses to your comments inline below. 

-- Abstract --
>there any chance to add 2 lines summarizing the 'how' ?

Added some more wording in the abstract to address your comment.
We have summarized the 'how' in the intro with a whole paragraph.
Probably better not to make the abstract overly long.
 
>I am sure that by now you know that you have to use RFC 8174 boilerplate ;-)

Yes. Done.

>For completeness and symmetry with section 2.3, please explain which packets

Good catch. Done.

>Please define "lateral peer" and why it is different to any other "peer".

Added Section 1.1. "Terminology" per your suggestion.
We've provided definitions of these terms and more there.

>term and the RIPE paper does not explain it either (of course I am not a

Definition of customer cone is also included in the Terminology section 1.1.

>suggest to have a (sub)section about "terminology" ?

Good suggestion. Done.

>CMTS was introduced as an acronym but not DSLAM.
Mention of DSLAM was not essential. So it is removed in the updated version.
Mention of CMTS, PDN-GW is sufficient in that context
and they are introduced.

Sriram

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Sat, 31 Aug 2019 06:39:11 +0000

Thank you Sriram for the updated document.

Just a minor nit: in the terminology section, P2C and C2P are in uppercase but p2p is in lower case. This can be fixed later at the AUTH48 stage

-éric

On 31/08/2019, 06:46, "Sriram, Kotikalapudi (Fed)" <[email-masked]> wrote:

    Eric,

    -- Abstract --

    
    Yes. Done.

    Good catch. Done.

    

    Good suggestion. Done.

    Sriram

---

From: "Sriram, Kotikalapudi (Fed)" <[email-masked]>
Date: Sat, 31 Aug 2019 19:43:22 +0000

>Just a minor nit: in the terminology section, P2C and C2P are in uppercase but p2p is in lower case. This can be fixed later at the AUTH48 stage 

The p in p2p (peer-to-peer) is lower case on purpose.
We have upper case P for Provider.
So we use lower case p in p2p where neither is provider (in the mutual relationship), 
instead the two ASes are lateral peers to each other. 

Sriram 
________________________________________
From: Eric Vyncke (evyncke) <[email-masked]>
Sent: Saturday, August 31, 2019 2:39 AM
To: Sriram, Kotikalapudi (Fed); The IESG
Cc: [email-masked]; Sandra Murphy; [email-masked]; [email-masked]; Warren Kumari
Subject: Re: Éric Vyncke's No Objection on draft-ietf-opsec-urpf-improvements-03: (with COMMENT)

-éric

    Eric,

    https://gcc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Frfcdiff%3Furl2%3Ddraft-ietf-opsec-urpf-improvements-04.txt&amp;data=02%7C01%7Ckotikalapudi.sriram%40nist.gov%7C1f83276d8d6349219f8508d72dddf2cc%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C637028303598920995&amp;sdata=srvqXLDHEnlIwoIZApGGHcVAQJDfUxQb1n60djHlikU%3D&amp;reserved=0

    -- Abstract --

    Yes. Done.

    Good catch. Done.

    Good suggestion. Done.

    Sriram