Re: [OPSEC] Éric Vyncke's No Objection on draft-ietf-opsec-urpf-improvements-03: (with COMMENT)
>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) Sent: Saturday, August 31, 2019 2:39 AM To: Sriram, Kotikalapudi (Fed); The IESG Cc: draft-ietf-opsec-urpf-improveme...@ietf.org; Sandra Murphy; opsec-cha...@ietf.org; opsec@ietf.org; Warren Kumari Subject: Re: Éric Vyncke's No Objection on draft-ietf-opsec-urpf-improvements-03: (with COMMENT) 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)" wrote: 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://gcc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Frfcdiff%3Furl2%3Ddraft-ietf-opsec-urpf-improvements-04.txt&data=02%7C01%7Ckotikalapudi.sriram%40nist.gov%7C1f83276d8d6349219f8508d72dddf2cc%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C637028303598920995&sdata=srvqXLDHEnlIwoIZApGGHcVAQJDfUxQb1n60djHlikU%3D&reserved=0 Please also see responses to your comments inline below. -- 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' ? > 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. >-- Section 1.1 -- >I am sure that by now you know that you have to use RFC 8174 boilerplate ;-) > Yes. Done. >-- Section 2.2 -- >For completeness and symmetry with section 2.3, please explain which packets >will be dropped. > Good catch. Done. >-- 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". > Added Section 1.1. "Terminology" per your suggestion. We've provided definitions of these terms and more there. >-- 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). > Definition of customer cone is also included in the Terminology section 1.1. >== NITS == > >-- Section 1 -- >Beside the intro, this section also introduces some terminology wording. May I >suggest to have a (sub)section about "terminology" ? > Good suggestion. Done. >-- Section 2.1 -- >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 ___ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec
Re: [OPSEC] Éric Vyncke's No Objection on draft-ietf-opsec-urpf-improvements-03: (with COMMENT)
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)" wrote: 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 -- >The abstract reads like 'promises' but not as a summary of the document. Is >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. >-- Section 1.1 -- >I am sure that by now you know that you have to use RFC 8174 boilerplate ;-) > Yes. Done. >-- Section 2.2 -- >For completeness and symmetry with section 2.3, please explain which packets >will be dropped. > Good catch. Done. >-- 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". > Added Section 1.1. "Terminology" per your suggestion. We've provided definitions of these terms and more there. >-- 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). > Definition of customer cone is also included in the Terminology section 1.1. >== NITS == > >-- Section 1 -- >Beside the intro, this section also introduces some terminology wording. May I >suggest to have a (sub)section about "terminology" ? > Good suggestion. Done. >-- Section 2.1 -- >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 ___ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec
Re: [OPSEC] Éric Vyncke's No Objection on draft-ietf-opsec-urpf-improvements-03: (with COMMENT)
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 -- >The abstract reads like 'promises' but not as a summary of the document. Is >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. >-- Section 1.1 -- >I am sure that by now you know that you have to use RFC 8174 boilerplate ;-) > Yes. Done. >-- Section 2.2 -- >For completeness and symmetry with section 2.3, please explain which packets >will be dropped. > Good catch. Done. >-- 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". > Added Section 1.1. "Terminology" per your suggestion. We've provided definitions of these terms and more there. >-- 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). > Definition of customer cone is also included in the Terminology section 1.1. >== NITS == > >-- Section 1 -- >Beside the intro, this section also introduces some terminology wording. May I >suggest to have a (sub)section about "terminology" ? > Good suggestion. Done. >-- Section 2.1 -- >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 ___ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec