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

[Di Ma]

Hi, Alvaro,

Thanks.

A new version (-06) has been submitted.

Di

> 在 2018年2月7日，01:48，Alvaro Retana  写道：
> 
> On February 5, 2018 at 10:09:18 PM, Di Ma (m...@zdns.cn) wrote:
> 
> Di:
> 
> Hi!
> 
>> A new version (-05) has been submitted for you to review.
> 
> There’s one more change I need you to make before starting the IETF Last Call.
> 
> In this latest revision you listed rfc8211 as a Normative Reference (as a 
> replacement of draft-ietf-sidr-adverse-actions, which was listed as 
> Informative).  Please move rfc8211 back to Informative.  I know this sounds 
> like a nit, but the IETF Last Call explicitly calls out DownRefs (pointing to 
> an Informational document as a Normative Reference in a Standards Track 
> document), which carry additional process…and in this case it is not needed.
> 
> While you’re at it, please update the reference to rfc7159 -> rfc8259.
> 
> Thanks!
> 
> Alvaro.

___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

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

[Di Ma]

Sriram,

Thanks again for your comments.


> 在 2018年1月30日，04:36，Sriram, Kotikalapudi (Fed)  
> 写道：
> 
> David, Di, Tim:
> 
> These are minor comments in alignment with Alvaro’s.
> 
> Alvaro wrote:
> 
>> M4. References:
> 
>> M4.1. s/I-D.ietf-sidr-bgpsec-overview/rfc8205  ...and should be Normative.
> 
>> 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
>>  
> 
> 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.


Yes.  We should make the change.


> 
> 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.

Agreed.

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

Di


> 
> Thanks.
> 
> Sriram
> ___
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr

___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

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

[Di Ma]

Hi, Alvaro,

Thanks for your comments.

Please see my responses in lines.

> 在 2018年1月30日，02:21，Alvaro Retana  写道：
> 
> 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?
> 

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. 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
>  
> 
> 

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.

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

Agreed.

Di
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

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

[Di Ma]

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)  
> 写道：
> 
> David, Di, Tim:
>  
> These are minor comments in alignment with Alvaro’s.
>  
> Alvaro wrote:
>  
> >M4. References:
>  
> >M4.1. s/I-D.ietf-sidr-bgpsec-overview/rfc8205  ...and should be Normative.
>  
> >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
> > 
>  
> 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
> ___
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr

___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

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

[Sriram, Kotikalapudi (Fed)]

David, Di, Tim:

These are minor comments in alignment with Alvaro’s.

Alvaro wrote:

>M4. References:

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

>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

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
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr