Re: [Gen-art] [EXT] Re: Genart last call review of draft-ietf-extra-imap-fetch-preview-09

[Alissa Cooper]

Meral, thanks for your review. Michael, thanks for the update. I entered a No 
Objection ballot.

Alissa


> On Sep 20, 2020, at 10:52 PM, Barry Leiba  wrote:
> 
> That looks good to me, Michael.
> 
> Barry
> 
> On Sun, Sep 20, 2020 at 10:35 PM Michael Slusarz 
> mailto:michael.slus...@open-xchange.com>> 
> wrote:
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> How about changing the first paragraph of Section 3.2 to the following:
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> "The server returns a variable-length string that is the generated preview 
> for that message.  This string is intended to be viewed by the user as a 
> contextual preview of the entire message, and is not intended to be 
> interpreted in any way by the client software."
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Slightly altered Barry's wording - "user" is already defined in Section 2 as 
> the human user, so to be consistent I think we should use "user" instead of 
> "end-user".
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> michael
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>> 
>> 
>> 
>> 
>> On 09/15/2020 3:26 PM Barry Leiba > > wrote:
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> Meral, thanks for the review.  The document does say in the first sentence 
>> of the Introduction that the preview is for the end user.  I agree that it 
>> would be useful to emphasize that, though, and I think the right place to do 
>> it is by adding to the first paragraph of Section 3.2 something like the 
>> following: “The preview string is meant to help the end-user, and is not 
>> intended to be interpreted in any way by the client software.”
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> Barry
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> On Tue, Sep 15, 2020 at 4:52 PM Meral Shirazipour via Datatracker 
>> mailto:nore...@ietf.org>> wrote:
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> Reviewer: Meral Shirazipour
>> 
>> 
>> 
>> 
>> 
>> Review result: Ready with Nits
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> I am the assigned Gen-ART reviewer for this draft. The General Area
>> 
>> 
>> 
>> 
>> 
>> Review Team (Gen-ART) reviews all IETF documents being processed
>> 
>> 
>> 
>> 
>> 
>> by the IESG for the IETF Chair.  Please treat these comments just
>> 
>> 
>> 
>> 
>> 
>> like any other last call comments.
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> For more information, please see the FAQ at
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> > >.
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> Document: draft-ietf-extra-imap-fetch-preview-09
>> 
>> 
>> 
>> 
>> 
>> Reviewer: Meral Shirazipour
>> 
>> 
>> 
>> 
>> 
>> Review Date: 2020-09-15
>> 
>> 
>> 
>> 
>> 
>> IETF LC End Date: 2020-09-14
>> 
>> 
>> 
>> 
>> 
>> IESG Telechat date: Not scheduled for a telechat
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> Summary: This draft is ready to be published as Standards Track RFC but I 
>> have
>> 
>> 
>> 
>> 
>> 
>> some comments.
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> Major issues:
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> Minor issues:
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> Nits/editorial comments: In Section 4.2, it would have been good to give some
>> 
>> 
>> 
>> 
>> 
>> example and advice on when the client uses the preview to take some action. 
>> Is
>> 
>> 
>> 
>> 
>> 
>> this to be avoided? (Was not very clear to me).
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> Best Regards,
>> 
>> 
>> 
>> 
>> 
>> Meral Shirazipour
>> 
>> 
>> 
>> 
>> 
>> www.ericsson.com 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
> 
> 
> 
> 
> ___
> Gen-art mailing list
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Genart last call review of draft-ietf-calext-jscalendar-25

[Alissa Cooper]

Robert, thanks for your review. Neil, thanks for the updates. I entered a No 
Objection ballot.

Alissa


> On Mar 7, 2020, at 9:58 PM, Neil Jenkins  wrote:
> 
> Thanks for the review Robert.
> 
>> ABNF is used, but there is no reference to RFC 5234.
> 
> I have added a normative reference to this RFC. 
> 
>> The first registry in section 8.4.3 should be explicit that it is a registry 
>> for values of the "@type" property.
> 
> That's not quite correct; the registry is for the names of types. Not all 
> types have an "@type" property (for example, primitive types like 
> UnsignedInt). The "@type" property is primarily to help where the context 
> allows multiple types (e.g. the "entries" property in a JSGroup object is a 
> list of JSEvent and/or JSTask objects, so you need the @type property on 
> these to know which one you are getting).
> 
>> It's not stated clearly whether a patch should succeed or fail if the 
>> resulting
>> object doesn't meet this specification's requirements. 
> 
> Good spot. I have added a requirement for the PatchObject to be valid that:
> 
> The value for the patch MUST be valid for the property being set (of the 
> correct type and obeying any other applicable restrictions), or if null the 
> property MUST be optional.
> 
> (Thus if this is not true the whole PatchObject should be ignored, as per any 
> other patch failure.)
> 
>> Side question: if a patch changes 'updated' (4.1.6) in an object that didn't 
>> already have a 'created' (4.1.5), should it fail if it doesn't also result 
>> in an object that has a 'created'? Or is it ok to lose the original creation 
>> time information?
> 
> No, this doesn't fail. The "created" property is optional, so you can have an 
> object that doesn't record its creation date.
> 
>> The security consideration section only points to section 7 of RFC 3986 for
>> potential issues related to the URIs that can be carried in this
>> representation. I don't think that's sufficient. There should be some
>> discussion (or a pointer to discussions) about the potential for malicious
>> construction of jscalendar objects containing potentially very large numbers 
>> of
>> URIs in, say, as Link objects (4.2.7). Is there an opportunity for amplified
>> attacks here? (Especially if these URLs might be automatically referenced by
>> any client, and even more so if the object is sent from a calendar with a 
>> large
>> number of subscribers.)
> 
> I have added:
> 
> A maliciously constructed JSCalendar object may contain a very large number 
> of URIs. In the case of published calendars with a large number of 
> subscribers, such objects could be widely distributed. Implementations should 
> be careful to limit the automatic fetching of linked resources to reduce the 
> risk of this being an amplification vector for a denial-of-service attack.
> 
>> Have you considered any tighter integrity checking for (4.2.7) links? Maybe a
>> checksum property?
> 
> No. The integrity of data is left to the transmission protocol and not part 
> of the data format being described in this document. I don't see any good 
> reason why this property should be subject to extra integrity checks beyond 
> the whole object.
> 
>> It doesn't look like application/jscalendar+json has had a media type review.
> 
> Thanks, I have now sent this for review.
> 
>> Nits:
> 
> I have addressed these, thanks for noting them. One comment:
> 
>> I don't expect anything to change at this point, but I do have to point to 
>> the
>> dissonance in the conventions A[] and A[B]. It would have been far less
>> confusing for A have the same semantic in both cases (preferably value), than
>> the current situation where it means value for A[], but key for A[B].
> 
> I see your point, but we have already used the same syntax in JMAP 
> (RFC8620/8621) and I think it is better to stay consistent.
> 
> I have published v26 
>  with all of the 
> above updates.
> 
> Cheers,
> Neil.
> ___
> Gen-art mailing list
> Gen-art@ietf.org 
> https://www.ietf.org/mailman/listinfo/gen-art 
> 
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] [regext] Genart last call review of draft-ietf-regext-rdap-sorting-and-paging-15

[Alissa Cooper]

Vijay, thanks for your review. Mario, Barry, thanks for your responses aand the 
new appendix. I entered a No Objection ballot.

Alissa


> On Aug 18, 2020, at 9:52 AM, Vijay Gurbani  wrote:
> 
> On Mon, Aug 17, 2020 at 2:57 PM Barry Leiba  > wrote:
> Hi, Mario and Vijay.
> 
> 7942 says that the Implementation Status section is inappropriate to include 
> in an RFC because it’s transient information that changes, and is usually 
> obsolete quickly.
> 
> But I don’t interpret Vijay’s suggestion as asking you to leave the section 
> in the document in it’s entirety, but, rather, to put non-ephemeral 
> information about a reference implementation into an appendix.  If there’s a 
> stable implementation that can be used in that way, I think it would be 
> appropriate, and I agree with Vijay that it could be helpful to other 
> implementors to have that information available.
> 
> Dear Barry and Mario: Thanks for paying attention to my review, and Barry is 
> indeed correct.  
> 
> Especially that the two implementations listed in the implementation section 
> appear to be almost fully conformant to the draft, and also appear to have 
> reasonable documentation, etc. around them.  It would seem to be a waste of 
> code to simply take this section out without preserving the good work done 
> here that can get other implementers started immediately.
> 
> Cheers,
> 
> - vijay
> ___
> Gen-art mailing list
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Genart last call review of draft-ietf-cellar-ffv1-16

[Alissa Cooper]

Joel, thanks for your review. Spencer, thanks for helping to get Joel’s 
comments addressed. I entered a No Objection ballot.

Alissa


> On Jul 16, 2020, at 11:17 AM, Spencer Dawkins at IETF 
>  wrote:
> 
> Hi, Joel, 
> 
> On Mon, Jul 13, 2020 at 11:17 PM Joel Halpern via Datatracker 
> mailto:nore...@ietf.org>> wrote:
> Reviewer: Joel Halpern
> Review result: Ready
> 
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
> 
> For more information, please see the FAQ at
> 
>  >.
> 
> Document: draft-ietf-cellar-ffv1-16
> Reviewer: Joel Halpern
> Review Date: 2020-07-13
> IETF LC End Date: 2020-07-16
> IESG Telechat date: Not scheduled for a telechat
> 
> Summary: This document appears to be ready for publication as an Informational
> RFC.
> 
> *I would have raised question about the intended status, but it appears that
> this is an established IETF convention and I see no reason to argue.)
> 
> Major issues:
> 
> Minor issues:
> Section 3.4 (Context) introduces the notation Q_{#}[ subscript }.  As that
> is the first reference to Q_{#}, it is rather confusing to the reader.  I
> grant that the term is defined in the next section (3.5).  Couldn't they 
> be
> reversed?
> 
> Section 3.8.1.1 refers to C(i), C_{i}, and C_i.  Are these all the same
> thing.
> 
> Section 3.8.1.2 refers to get-rac (which is treated as a function in the
> pseudo-code) as being the process described in section 3.8.1.1.  The text
> in 3.8.1.1 does not call out any of its computed values as an explicit
> result or return.  While I would guess that the intention is to use the
> byte stream (B()), the text does not actually say that.  If that is the
> intention, could the last line of 3.8.1.1 be "get_rac() returns sequential
> bytes from the Byte Stream (B()) as computed by the computation described
> in section 3.8.1.1"?
> 
> Nits/editorial comments:
> 
> Thanks for the review! We'll work through these comments.
> 
> Best,
> 
> Spencer 
> ___
> Gen-art mailing list
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Genart early review of draft-ietf-cellar-ffv1-03

[Alissa Cooper]

Matt, thanks for your (long-ago) review. Dave, thanks for addressing Matt’s 
comments.

Alissa

> On Jul 6, 2018, at 1:50 PM, Matthew A. Miller 
>  wrote:
> 
> Thanks Dave for the quick work!  I've read through the PR and commits
> you provided, and think it will be in much better shape.  I look forward
> to reviewing the next published revision.
> 
> I've made contextual responses below to outstanding questions.
> 
> On 18/07/06 09:23, Dave Rice wrote:
>> Hi,
>> Thank you Matthew for this detailed review. Here are my comments related
>> to a PR at https://github.com/FFmpeg/FFV1/pull/119 which responds to
>> some of these comments. Other comments below may require more discussion.
>> 
>>> On Jul 5, 2018, at 5:00 PM, Matthew Miller
>>> >> > wrote:
>>> 
>>> Reviewer: Matthew Miller
>>> Review result: On the Right Track
>>> 
>>> I am the assigned Gen-ART reviewer for this draft. The General Area
>>> Review Team (Gen-ART) reviews all IETF documents being processed
>>> by the IESG for the IETF Chair.  Please treat these comments just
>>> like any other last call comments.
>>> 
>>> For more information, please see the FAQ at
>>> 
>>> .
>>> 
>>> Document: draft-ietf-cellar-ffv1-03
>>> Reviewer: Matthew A. Miller
>>> Review Date: 2018-07-05
>>> IETF LC End Date: N/A
>>> IESG Telechat date: N/A
>>> 
>>> Summary:
>>> 
>>> This document is moving in the right direction, but needs
>>> work.  Overall, the document feels unfinished.  It's clear
>>> a lot of work has gone into this, and there's been tremendous
>>> effort put into the details.  However, it's lacking some
>>> clarity, that was present in older revisions that were removed;
>>> speculatively is it due to more generic coverage that
>>> later revisions covered?
>> 
>> I’m not sure I understand as it hasn’t seemed like many parts have been
>> removed during the drafting work. Could you provide an example?
>> 
> 
> When I first opened this document, I felt overwhelmed by some of the
> terminology and unclear on what the structure/architecture was, so I did
> some spelunking.  It's largely why I took my review is five days late
> despite having 30 days to get through it (that, and I still
> procrastinated some in the middle).
> 
> I went all the way back to versions prior to WG adoption and saw there
> were some additional prose throughout; although it seemed the earlier
> revisions were more restricted in what could be represented in FFV1 than
> the current document allows, it helped me better understand.
> 
> I apologize for not taking more detailed note of which sections in those
> previous revisions helped me the most, but I can try to do that.
> However, I think the additions and reorganization in the PR goes a long
> way to helping already.
> 
>>> The introduction is quite helpful in answering the inevitable
>>> question "What is a FFV1?".  For the most part, the flow of
>>> the document seems to make sense.
>>> 
>>> Major issues:
>>> 
>>> I can understand relying on pseudo-code for something very math-
>>> and/or algorithm-heavy, but some prose would be quite helpful in
>>> understanding how and why the parts relate to one another.  The
>>> Definitions section is essentially what I would look for, but only
>>> accounts for some of the terms used within the rest of the
>>> document.  As written, this document depends entirely on the
>>> reader being intimately familiar with the subject matter.
>> 
>> This has been discussed before and I’ve appreciated how some other IETF
>> documents which include pseudo-code include an “as read” narrative
>> version of the code as well. I think there may have been some concern of
>> any risk of discrepancy between what the pseudo-code and the narrative
>> of the pseudo-code communicate. If anyone know some boilerplate for
>> managing this, please share.
>> 
> 
> My experience has been that (pseud-)code is great to cover the details,
> but the overall forest can get lost reading each tree.  I think the
> additional terms added plus some of the reorganizing addresses this
> concern, but I'd need to re-read the document with all the changes to be
> sure.
> 
>>> Minor issues:
>>> 
>>> * Please consider moving the text of Section 2.2.6. "Pseudo-code"
>>> up a level to 2.2. "Conventions" or as the first sub-section under
>>> 2.2. "Conventions".  This points seems to me to warrant more
>>> significance than it currently has.
>> 
>> I started a pull request at https://github.com/FFmpeg/FFV1/pull/119 and
>> moved this section.
>> 
>>> * In reading this, I wondered if it would help improve the
>>> understanding of this document if Sections 3. and 4. swapped
>>> places.  I think it's worth considering, but accept this
>>> suggestion could be rejected.
>> 
>> I reviewed these sections and feel hesitant swapping the order outright.
>> Any other comments from cellar on this proposal?
>> 
> 
> I personally felt I had a better grasp of the document afte