Subject: [sidr] AD Review of draft-ietf-sidr-slurm-04

From: Alvaro Retana <[email-masked]>
Date: Mon, 29 Jan 2018 10:21:13 -0800

Dear authors:

I just finished reading this document.

I have some comments (below) that should be easy to address — please take a
look.  I need you to address the References before I start the IETF Last
Call because of the DownRef to rfc6483.

Thanks!

Alvaro.

Major:

M1. Section 3.1:  I'm not sure what the Normative result is form this piece
of text: "JSON members that are not defined here MUST not be used in SLURM
Files, however Relying Parties SHOULD ignore such unrecognized JSON members
at the top level, while any deviations from the specification at lower
levels MUST be considered an error."  (s/MUST not/MUST NOT)  If the not
defined members MUST NOT be used, when would the RPs not ignore (or even
better, treat as errors) them?  IOW, why use SHOULD instead of MUST?

M2. Section 4.2: "Before an RP configures SLURM files from different source
it MUST make sure there is no internal conflict among the INR assertions in
these SLURM files.  To do so, the RP SHOULD check the entries of SLURM
file..."  I think there's a Normative mismatch: "MUST make
sure...no...conflict" vs "SHOULD check the entries"; the SHOULD leaves the
door open to not always checking -- are there cases when the entries
wouldn't be checked *and* the MUST can still be guaranteed?  It seems to me
like both keywords should be MUST.

M3. Section 6: "...but if the RP updates its SLURM file over the network,
it MUST verify the authenticity and integrity of the updated SLURM file."
 Please indicate that the mechanism to update files, and the
authentication/integrity verification are outside the scope of this
document.

M4. References:

M4.1. s/I-D.ietf-sidr-bgpsec-overview/rfc8205  ...and should be Normative.

M4.2. I believe the following references should also be Normative:
ietf-sidr-rpki-rtr-rfc6810-bis/rfc8210, rfc6483, rfc6810, rfc6811 and
rfc7159.

M4.3. [minor] Please update the references according to the Nits [1].

[1]
https://tools.ietf.org/idnits?url=https://tools.ietf.org/id/draft-ietf-sidr-slurm-04.txt

Minor:

P1. "Relying party software MAY modify other forms of output in comparable
ways, but that is outside the scope of this document."  If it's out of
scope, then there shouldn't be any Normative language. s/MAY/may

P2. "Locally Added Assertions" are sometimes called "Locally Adding
Assertions".

Nits:

N1. s/control make use of RPKI data/control use of RPKI data

---

From: "Sriram, Kotikalapudi (Fed)" <[email-masked]>
Date: Mon, 29 Jan 2018 20:36:51 +0000

David, Di, Tim:

These are minor comments in alignment with Alvaro’s.

>[1] https://tools.ietf.org/idnits?url=https://tools.ietf.org/id/draft-ietf-sidr-slurm-04.txt<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fidnits%3Furl%3Dhttps%3A%2F%2Ftools.ietf.org%2Fid%2Fdraft-ietf-sidr-slurm-04.txt&data=02%7C01%7Ckotikalapudi.sriram%40nist.gov%7Cc59432d1b20b4ceb46a508d567451e8e%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636528468933957141&sdata=5QbjZdDuSy9CgDHN4gKAPsJ5EpRwJbFIVpn6Lh7d7D0%3D&reserved=0>

With regard to updating the references, I noticed that the draft references
[I-D.ietf-sidr-bgpsec-overview] in two places where it should reference
BGPsec Protocol Specification [RFC 8205].  For example, on page 3:

(Validation of the origin of a route is
   described in [RFC6483], and validation of the path of a route is
   described in [I-D.ietf-sidr-bgpsec-overview].)

For “validation of the path of a route” the pointer should be Section 5 of RFC 8205.

AFAIK, [I-D.ietf-sidr-bgpsec-overview] is expired and there are no plans to publish it.

I would also suggest that both RFCs 6483 and 6811 can be referenced when
talking about “Validation of the origin of a route.”  RFC 6811 is Standards Track
while 6483 is Informational.

Thanks.

Sriram

---

From: Di Ma <[email-masked]>
Date: Wed, 31 Jan 2018 16:39:09 +0800

Sriram,

Thanks for your comments.

We authors will update the draft, in response to your suggestions and comments from the AD.

Di

> 在 2018年1月30日，04:36，Sriram, Kotikalapudi (Fed) <[email-masked]> 写道：
> 
> David, Di, Tim:
>  
> >[1] https://tools.ietf.org/idnits?url=https://tools.ietf.org/id/draft-ietf-sidr-slurm-04.txt 
>  
> _______________________________________________
> sidr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidr

---

From: Di Ma <[email-masked]>
Date: Wed, 31 Jan 2018 23:18:52 +0800

Hi, Alvaro,

Please see my responses in lines.

> 在 2018年1月30日，02:21，Alvaro Retana <[email-masked]> 写道：
> 
> Dear authors:
> 
> I have some comments (below) that should be easy to address — please take a look.  I need you to address the References before I start the IETF Last Call because of the DownRef to rfc6483.
> 
> Thanks!
> 
> Alvaro.
> 
> 
> 
> Major:
> 
> M1. Section 3.1:  I'm not sure what the Normative result is form this piece of text: "JSON members that are not defined here MUST not be used in SLURM Files, however Relying Parties SHOULD ignore such unrecognized JSON members at the top level, while any deviations from the specification at lower levels MUST be considered an error."  (s/MUST not/MUST NOT)  If the not defined members MUST NOT be used, when would the RPs not ignore (or even better, treat as errors) them?  IOW, why use SHOULD instead of MUST?
> 

We authors think MUST is better than SHOULD.

And we would like to update section 3.1 saying:

"This document describes responses in the JSON [RFC7159] format.  JSON members that are not defined here MUST not be used in SLURM Files and additional top-level members MUST be defined in RFCs that update this document. Relying parties MUST ignore unrecognized JSON members at the top level, while any deviations from the specification at lower levels MUST be considered an error.”

Here is the consideration: 
The current document describes local exceptions with regards to ROAs and Router Certificates, which are significant to local control of routing.  The thought here was that we would leave an option for future other ’top-level’ elements to describe local exceptions with regards to other (future) RPKI objects as long as they have fundamental effect in routing control , while maintaining backward compatibility. But this is not explicit in the document as written. The risk here, as written, is that implementations can just add stuff at will for their own purpose and we can end up with the same member name being re-used.

> 
> 
> M2. Section 4.2: "Before an RP configures SLURM files from different source it MUST make sure there is no internal conflict among the INR assertions in these SLURM files.  To do so, the RP SHOULD check the entries of SLURM file..."  I think there's a Normative mismatch: "MUST make sure...no...conflict" vs "SHOULD check the entries"; the SHOULD leaves the door open to not always checking -- are there cases when the entries wouldn't be checked *and* the MUST can still be guaranteed?  It seems to me like both keywords should be MUST.

Yes. 

You are making sense here. 

> 
> 
> M3. Section 6: "...but if the RP updates its SLURM file over the network, it MUST verify the authenticity and integrity of the updated SLURM file."  Please indicate that the mechanism to update files, and the authentication/integrity verification are outside the scope of this document.

Agreed. 

We are going to add:

"Yet the mechanism to update SLURM file to guarantee authentication and integrity is out of  the scope of this document. "

Besides, we need to change ‘source’ to ‘sources’ :-)

> M4.2. I believe the following references should also be Normative: ietf-sidr-rpki-rtr-rfc6810-bis/rfc8210, rfc6483, rfc6810, rfc6811 and rfc7159.
> 

Agreed. 

> 
> Minor:
> 
> P1. "Relying party software MAY modify other forms of output in comparable ways, but that is outside the scope of this document."  If it’s out of scope, then there shouldn't be any Normative language. s/MAY/may

Agreed.

> 
> P2. “Locally Added Assertions" are sometimes called "Locally Adding Assertions".

We authors are going to change 4.1 and 4.2 to say “Locally Added Assertions” because we refer to the elements.

The lower case “locally adding assertions” in 3.2 is fine, because it describes an action.

> N1. s/control make use of RPKI data/control use of RPKI data

Agreed.

Di

---

From: Di Ma <[email-masked]>
Date: Wed, 31 Jan 2018 23:26:12 +0800

Sriram,

Thanks again for your comments.

> For “validation of the path of a route” the pointer should be Section 5 of RFC 8205.

Yes.  We should make the change.

Agreed.

RFC 6811 is more competent to talk about Validation of the origin of a route. 

Di

---

From: Alvaro Retana <[email-masked]>
Date: Wed, 31 Jan 2018 07:39:35 -0800

Di:

Hi!

Thanks for your prompt reply.  I look forward to an updated draft.

Alvaro.

On January 31, 2018 at 10:18:57 AM, Di Ma ([email-masked]) wrote:

Hi, Alvaro,

> I have some comments (below) that should be easy to address — please take
a look. I need you to address the References before I start the IETF Last
Call because of the DownRef to rfc6483.
>
> Thanks!
>
> Alvaro.
>
>
>
> Major:
>
> M1. Section 3.1: I'm not sure what the Normative result is form this
piece of text: "JSON members that are not defined here MUST not be used in
SLURM Files, however Relying Parties SHOULD ignore such unrecognized JSON
members at the top level, while any deviations from the specification at
lower levels MUST be considered an error." (s/MUST not/MUST NOT) If the not
defined members MUST NOT be used, when would the RPs not ignore (or even
better, treat as errors) them? IOW, why use SHOULD instead of MUST?

"This document describes responses in the JSON [RFC7159] format. JSON
members that are not defined here MUST not be used in SLURM Files and
additional top-level members MUST be defined in RFCs that update this
document. Relying parties MUST ignore unrecognized JSON members at the top
level, while any deviations from the specification at lower levels MUST be
considered an error.”

Here is the consideration:
The current document describes local exceptions with regards to ROAs and
Router Certificates, which are significant to local control of routing. The
thought here was that we would leave an option for future other ’top-level’
elements to describe local exceptions with regards to other (future) RPKI
objects as long as they have fundamental effect in routing control , while
maintaining backward compatibility. But this is not explicit in the
document as written. The risk here, as written, is that implementations can
just add stuff at will for their own purpose and we can end up with the
same member name being re-used.

>
>
> M2. Section 4.2: "Before an RP configures SLURM files from different
source it MUST make sure there is no internal conflict among the INR
assertions in these SLURM files. To do so, the RP SHOULD check the entries
of SLURM file..." I think there's a Normative mismatch: "MUST make
sure...no...conflict" vs "SHOULD check the entries"; the SHOULD leaves the
door open to not always checking -- are there cases when the entries
wouldn't be checked *and* the MUST can still be guaranteed? It seems to me
like both keywords should be MUST.

Yes.

Agreed.

We are going to add:

"Yet the mechanism to update SLURM file to guarantee authentication and
integrity is out of the scope of this document. "

Agreed.

>
> Minor:
>
> P1. "Relying party software MAY modify other forms of output in
comparable ways, but that is outside the scope of this document." If it’s
out of scope, then there shouldn't be any Normative language. s/MAY/may

Agreed.

> P2. “Locally Added Assertions" are sometimes called "Locally Adding
Assertions".

We authors are going to change 4.1 and 4.2 to say “Locally Added
Assertions” because we refer to the elements.

The lower case “locally adding assertions” in 3.2 is fine, because it
describes an action.

Agreed.

Di