Hi Richard,

The concern is that RFC7396 could be updated by another RFC or even obsoleted. 
Therefore duplicating any formal specification should be avoided and it’s 
actually a feature that people have to look up RFC7396. I recommend to remove 
the pseudo code and replace it by a few sentences that loosely described the 
scheme.

Mirja



> On 11. Mar 2020, at 21:49, Y. Richard Yang <[email protected]> wrote:
> 
> Dear Suresh,
> 
> Thanks for the review! Please see inline.
> 
> On Wed, Mar 11, 2020 at 12:20 PM Suresh Krishnan via Datatracker 
> <[email protected]> wrote:
> Suresh Krishnan has entered the following ballot position for
> draft-ietf-alto-incr-update-sse-20: No Objection
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-alto-incr-update-sse/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Section 3.1.1.:
>   I feel strongly that this document should not restate the pseudo-code for 
> the
>   JSON merge patch algorithm and should instead use a reference to Section 2 
> of
>   RFC7396 instead. This will avoid inconsistencies (e.g. note that the pseudo
>   code in this draft is *already different* from that in RFC7396 even though
>   the difference is only the braces) and be amenable to updates to RFC7396.
> 
> 
> This is an interesting discussion point. In an earlier version, the authors 
> had some back-and-forth on including the pseudo-code or not. The "include" 
> argument "won" because it makes the document more self-contained and a 
> potentially more pleasant read---a reader does not need to track down a 
> separate document to find the pseudo-code, and we are referring to a "fixed" 
> document---I can see your argument that there can be Errata/Update to the 
> RFC7396 pseudocode. It is amazing that you caught the difference in braces vs 
> : ! One proposal is that we change to the exact format (replace braces with 
> {) as in RFC 7396 and keep the pseudocode. Or let the coauthors discuss a bit 
> more and get a conclusion in the next couple of days. How does this sound? 
>  
> References:
> 
> Is there a reason this document is using the obsoleted JSON reference to
> RFC7159? Suggest updating the reference to RFC8259.
> 
> 
> Good catch. We are updating to RFC 8259. Thanks!
> 
> Thanks again.
> Richard

_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto

Reply via email to