Hi, Alvaro,
A new version (-05) has been submitted for you to review.
The draft is updated based on the comments from you and Sriram.
And it places a more strict limit on the slurmVersion JOSN member compared to
the previous version by saying:
“Future additions to the specifications in this document MUST use an
incremented value for the “slurmVersion” member."
Di
> 在 2018年1月31日，23:39，Alvaro Retana <[email protected]> 写道：
>
> 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 protected]) wrote:
>
>> Hi, Alvaro,
>>
>> Thanks for your comments.
>>
>> Please see my responses in lines.
>>
>> > 在 2018年1月30日，02:21，Alvaro Retana <[email protected]> 写道：
>> >
>> > 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
> [email protected]
> https://www.ietf.org/mailman/listinfo/sidr
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
