Re: [Last-Call] Secdir last call review of draft-ietf-scim-cursor-pagination-02

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Barry,

We have published a new version(-04) of the Cursor Based Pagination Draft to the data tracker that addresses all the concerns raised by you in the email below.
https://datatracker.ietf.org/doc/draft-ietf-scim-cursor-pagination/

We have added 3 new sections 
- Section 2.4 Backward Compatibility Considerations
- Section 5 Security Considerations
- Section 6 IANA Considerations

Kindly request you to please review the draft.

Best Regards,
Anjali


On 2023-11-16, 2:19 PM, "Barry Leiba via Datatracker" <noreply@xxxxxxxx <mailto:noreply@xxxxxxxx>> wrote:


CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.






AVERTISSEMENT: Ce courrier électronique provient d’un expéditeur externe. Ne cliquez sur aucun lien et n’ouvrez aucune pièce jointe si vous ne pouvez pas confirmer l’identité de l’expéditeur et si vous n’êtes pas certain que le contenu ne présente aucun risque.






Reviewer: Barry Leiba
Review result: Serious Issues


Two fatal errors here:
This document lacks required Security Considerations and IANA Considerations
sections. It can’t proceed without them, and I can’t review the document
properly from a security standpoint without the former.


Other comments:


In the Abstract and Introduction, a nit:
“is already well established” should not be hyphenated, as it’s not a modifier
(whereas “a well-established pagination pattern” is correctly hyphenated).


— Section 2 —


The following table describes the URL pagination parameters requests
for using cursor-based pagination:


I think the word “requests” is extra and should be removed (or perhaps “using”
should be replaced by “requesting”).


In the second table you say “Use of previousCursor is OPTIONAL.” That seems to
say that using it in a subsequent request is optional, which is already said in
the previous sentence. I think this one should say, “Returning previousCursor
is OPTIONAL.”


— Section 2.3 —
This seems to make this not backward compatible: a client that doesn’t support
this won’t know what to do with the nextCursor parameter and will likely not
work correctly. Is it not worth making that clear in the text?







-- 
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux