Re: [Gen-art] Genart last call review of draft-ietf-cbor-tags-oid-05

[Barry Leiba]

Thanks for the review, Gyan.

Barry

On Sat, Mar 20, 2021 at 2:59 PM Gyan Mishra via Datatracker <
nore...@ietf.org> wrote:

> Reviewer: Gyan Mishra
> 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-cbor-tags-oid-??
> Reviewer: Gyan Mishra
> Review Date: 2021-03-20
> IETF LC End Date: 2021-03-24
> IESG Telechat date: Not scheduled for a telechat
>
> Summary:
> Document is ready for publication
> Major issues:
> None
>
> Minor issues:
> None
> Nits/editorial comments:
> None
>
>
>
>
___
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-cdni-uri-signing-21

[Barry Leiba]

Thanks for the review, Christer!

Barry

On Fri, Feb 19, 2021 at 4:39 PM Christer Holmberg via Datatracker
 wrote:
>
> Reviewer: Christer Holmberg
> 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-cdni-uri-signing-21
> Reviewer: Christer Holmberg
> Review Date: 2021-02-19
> IETF LC End Date: 2021-02-19
> IESG Telechat date: 2021-02-25
>
> Summary: The document is ready for publication. A very minor comment is that I
> do think that some of the paragraphs were quite long a detailed, and could
> perhaps have been split into separate paragraphs in order to make the text 
> more
> clear.
>
> Major issues: N/A
>
> Minor issues: N/A
>
> Nits/editorial comments: N/A
>
>
>

___
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-regext-rfc7482bis-02

[Barry Leiba]

Thanks for the review, Dan.

Your comment makes sense, yes.

Barry

On Thu, Feb 4, 2021 at 9:56 AM Dan Romascanu via Datatracker
 wrote:
>
> Reviewer: Dan Romascanu
> Review result: Ready with Issues
>
> 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-regext-rfc7482bis-02
> Reviewer: Dan Romascanu
> Review Date: 2021-02-04
> IETF LC End Date: 2021-02-08
> IESG Telechat date: Not scheduled for a telechat
>
> Summary:
>
> This Document is Ready with one issue that I would suggest to clarify and
> possibly apply edits before approval.
>
> Major issues:
>
> If my understanding is correct this document together with 7483bis will 
> replace
> RFC 7482 and RFC 7483 and advance them to Internet Standard. Sections 7 and 8
> will be taken out from the final published RFC. I believe that the 
> relationship
> with RFC 7482 needs to be detailed either in the Introduction or in a 
> dedicated
> version, in order to clarify for future readers and users the status of the 2 
> /
> 4 documents. I also believe that a shortened version of the 'Changes from RFC
> 7482' section now an Appendix should be included in the text of the document 
> in
> its final form.
>
> Minor issues:
>
> Nits/editorial comments:
>
>
>

___
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-regext-rfc7483bis-04

[Barry Leiba]

Thanks for the review, Joel.

Barry

On Thu, Jan 28, 2021 at 6:44 PM Joel Halpern via Datatracker <
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-regext-rfc7483bis-04
> Reviewer: Joel Halpern
> Review Date: 2021-01-28
> IETF LC End Date: 2021-02-08
> IESG Telechat date: Not scheduled for a telechat
>
> Summary: This document is ready for publication as an Internet Standard
>
> Major issues: N/A
>
> Minor issues: N/A
>
> Nits/editorial comments: N/A
>
>
>
>
___
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-crocker-inreply-react-07

[Barry Leiba]

> > 2.  Reaction Content-Disposition
> >
> >
> > The rule emoji_sequence is inherited from [Emoji-Seq].  It permits
> > one or more bytes to form a single presentation image.
> >
> > I haven't traced the definition of emoji_sequence, but it seems to be
> > essentially a set of Unicode characters that have one or another of
> > certain attributes.  That is perfectly sensible.  But if I understand
> > correctly, "emoji_sequence" is a sequence of characters, and you want
> > to say "In the UTF-8 encoding, some of these characters may be encoded
> > as multiple bytes." or something like that.
>
> Sorry but I'm not understanding what clarity this provides, over the
> existing text.
>
> To the extent that your intent is to say that a) this is a subset of
> UTF-8, and b) multiple bytes can be used, I think that's built into the
> definition of emoji-sequence.
>
> In fact, I had added the one or more text mostly to highlight the the
> 'sequence' can be only one byte, since 'sequence' would be expected to
> be read as meaning multiple.
>


I’m guessing that Dale is thinking that this is like composed characters,
such as creating “á” from “a” plus combining acute accent.  The thing is,
though, it’s not that.  What Dave is describing (perhaps an example in the
text would help explain) is the sort of thing that’s unique to emoji,
wherein the emojis for man followed by woman followed by boy, each of which
is a separate emoji character that would be displayed as it seems, will
often be rendered as a single image of a family, just because they’re coded
together.

I thunk the text that Dave has is correct — certainly more correct than the
suggestion, which would imply character composition rather than the image
composition that’s being discussed here.

I don’t think a change to the text will really help, but a “(for example,
...)” might.

Barry




>
___
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-extra-imap4rev2-24

[Barry Leiba]

Thanks for the review, Robert -- I know this one was heavy to lift,
and I particularly appreciate the time and effort.

Barry

On Thu, Jan 14, 2021 at 5:09 PM Robert Sparks via Datatracker
 wrote:
>
> Reviewer: Robert Sparks
> 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-extra-imap4rev2-24
> Reviewer: Robert Sparks
> Review Date: 2021-01-14
> IETF LC End Date: 2021-01-20
> IESG Telechat date: Not scheduled for a telechat
>
> Summary: Ready for publication as a Proposed Standard RFC
>
> I approached reviewing this document first by diffing it with RFC3501, then
> doing a linear read-through. Errata seem appropriately handled. This looks 
> like
> it was a huge effort - it is very well done. I sent the few nits I could find
> directly to the editors.
>
>

___
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-extra-sieve-mailboxid-05

[Barry Leiba]

> And yeah - if the latest mmark is causing artifacts I'll see what I can do 
> about those.  I admit I didn't
> read through the whole thing in detail again after making the last updates.

If it's easy to fix, please do, but don't get too wrapped up in
spending time on that: the RFC Editor will be converting it to xml2rfc
v3 anyway, and those issues will be resolved in that process.

Barry

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

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

[Barry Leiba]

That looks good to me, Michael.

Barry

On Sun, Sep 20, 2020 at 10:35 PM Michael Slusarz <
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 <
> 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
>
>
>
>
>
>
>
>
>
>
>
> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
>
>
>
>
>
>
>
>
>
>
>
> 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

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

[Barry Leiba]

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

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

[Barry Leiba]

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.

Barry

On Mon, Aug 17, 2020 at 8:26 AM Mario Loffredo 
wrote:

> Hi Vijay,
>
>
>
> thanks a lot for your review. I provide my responses to your feedback
> below.
>
>
>
> Il 16/08/2020 01:00, Vijay Gurbani via Datatracker ha scritto:
>
> > Reviewer: Vijay Gurbani
>
> > 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-regext-rdap-sorting-and-paging-??
>
> > Reviewer: Vijay K. Gurbani
>
> > Review Date: 2020-08-15
>
> > IETF LC End Date: 2020-08-13
>
> > IESG Telechat date: Not scheduled for a telechat
>
> >
>
> > Summary: The draft is ready for publication as a proposed standard, with
> a
>
> > couple of nits.
>
> >
>
> > Major issues: 0
>
> >
>
> > Minor issues: 0
>
> >
>
> > Nits/editorial comments: 2
>
> >
>
> > - Section 6: I understand that RFC7942 requests the authors to add a
> note to
>
> > the RFC Editor to remove this section, but I also understand that this
> is a
>
> > request to the author, and not a mandate (no normative language).   As an
>
> > implementer, I always find it easy to start with some bootstrapping
> code, so I
>
> > find such implementation notes helpful.  You may wish to consider
> including
>
> > this information in an Appendix.
>
>
>
> [ML] According to what is stated in RFC7942, the "Implementation Status"
>
> section "... is inappropriate for inclusion in a published RFC."
>
>
>
> Despite this, I would agree with you if that section included a client
>
> implementation because clients are more likely than servers to be
>
> publicly available as open source applications.
>
>
>
> Definitively, I believe that the examples included in the document are
>
> sufficient to explain the specification.
>
>
>
> Hope you are okay with that.
>
>
>
> >
>
> > - Section 1, towards end of Page 3: s/that could be/that is often/
> (Reason:
>
> > "could be" implies that truncation could happen, but is may not, "is
> often"
>
> > implies the same thing, but that phrase seems somehow more deterministic
> than
>
> > "could be".  This is a suggestion, please use your editorial discretion
> as
>
> > appropriate.)
>
>
>
> [ML] Sounds much better. I correct the phrase.
>
>
>
>
>
> Best,
>
>
>
> Mario
>
>
>
> >
>
> >
>
> > ___
>
> > regext mailing list
>
> > reg...@ietf.org
>
> > https://www.ietf.org/mailman/listinfo/regext
>
>
>
> --
>
> Dr. Mario Loffredo
>
> Systems and Technological Development Unit
>
> Institute of Informatics and Telematics (IIT)
>
> National Research Council (CNR)
>
> via G. Moruzzi 1, I-56124 PISA, Italy
>
> Phone: +39.0503153497
>
> Mobile: +39.3462122240
>
> Web: http://www.iit.cnr.it/mario.loffredo
>
>
>
>
___
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-regext-rdap-partial-response-12

[Barry Leiba]

Wow, David, thanks for the super-quick review!

Barry

On Fri, Jul 24, 2020 at 6:48 PM David Schinazi via Datatracker <
nore...@ietf.org> wrote:

> Reviewer: David Schinazi
> Review result: Ready with Issues
>
> 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-regext-rdap-partial-response-12
> Reviewer: David Schinazi
> Review Date: 2020-07-24
> IETF LC End Date: 2020-08-14
> IESG Telechat date: Not scheduled for a telechat
>
> Summary: Document is clear, well-written, and short. Thank you!
>
> Major issues: None
>
> Minor issues: After reading the document, I was somewhat
> confused as to the definition of fieldSet query parameter.
> I think adding a few sentences to Section 2 explaining that
> a field set is a string that the server generates which maps
> to a set of fields only known to the server would help.
> Additionally, specifying that the string can't be empty and
> which characters are allowed might help avoid interop
> issues down the road.
>
> Nits/editorial comments: None
>
>
>
>
___
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-httpbis-client-hints-13

[Barry Leiba]

Please post a revised I-D when you’re ready; thanks.

Barry

On Thu, May 7, 2020 at 6:02 AM Yoav Weiss  wrote:

> Addressed the latest points in the PR. Thanks! :)
>
> On Wed, May 6, 2020 at 3:20 PM Yoav Weiss  wrote:
>
>>
>>
>> On Wed, May 6, 2020 at 2:43 PM Christer Holmberg <
>> christer.holmb...@ericsson.com> wrote:
>>
>>> Hi Yoav,
>>>
>>> >> I have not received the pull request yet, so I will comment only
>>> based on your e-mail reply :)
>>> >
>>> > Apologies for the delay. PR is now up at
>>> https://protect2.fireeye.com/v1/url?k=0a42e34e-54e25920-0a42a3d5-
>>> >
>>> 869a14f4b08c-11c3f32cbd74f2f2=1=978d85da-fab3-4523-a8d9-447aa6bdf056=
>>> https://github.com/httpwg/http-extensions/pull/1171
>>>
>>> Thanks!
>>>
>>> I think it looks ok.
>>>
>>> BTW, are high-entropy and low-entropy defined and well-known HTTP terms?
>>>
>>
>> I'm not sure. The browser processing model defines a list of low-entropy
>> CH headers:
>> https://wicg.github.io/client-hints-infrastructure/#low-entropy-table
>> I could point at that.
>>
>>
>>> ---
>>>
>>> MaQ3:
>>>
>>>  Related to MaQ2, what happens if a server receives hints that it
>>> does not
>>>  understand, or does not support?
>>> >>>
>>> >>> Servers SHOULD ignore hints they do not understand or do not support.
>>> >>
>>> >> Is there are reason for not using MUST? SHOULD typically means
>>> MUST-unless-X. What would X be?
>>> >>
>>> >> Is there a way for the server to indicate to the client that it did
>>> not understand/support the hints? Whatever the answer, I think it would be
>>> good to have some text about that.
>>> >
>>> > There's no such a mechanism, similar to other request headers.
>>> > Do you have sample text in mind that may make that point clearer?
>>>
>>> Maybe just a note pointing out that there is no mechanism for a server
>>> to inform a client whether it understands and supports the hints.
>>>
>>> ---
>>>
>>> Minor issues:
>>>
>>> MiQ1:
>>>
>>> >>> Section 1 described that proactive content negotiation allows
>>> servers to
>>> >>> silently fingerprint the user agent.
>>> >>>
>>> >>> But, later in the Section it is described that Client Hints also
>>> allow a server
>>> >>> the perform fingerprinting, and the Security Considerations also say
>>> that there
>>> >>> is really no difference.
>>> >>>
>>> >>> So, does Section 1 need to talk about fingerprinting at all?
>>> >>
>>> >> Section 1 describes the fact that traditional (read: pre-Client
>>> Hints) content negotiation methods relied on sending information to all
>>> servers, which enabled passive fingerprinting,
>>> >> and how Client Hints breaks away from that paradigm, by only sending
>>> (high entropy) hints when the server needs them and opts-in to receive them.
>>> >>
>>> >> A server can request the hints even if it doesn't "need" them, but it
>>> wants to do fingerprinting. The client does not know what the server will
>>> do with the information.
>>> >>
>>> >> My point is that the reader should not get an impression that client
>>> hints somehow prevents fingerprinting. It doesn't. The only difference is
>>> that the server has to ask for the information.
>>> >
>>> > Current draft includes " Client Hints mitigate ... privacy concerns of
>>> passive fingerprinting by requiring explicit opt-in and disclosure of
>>> > required headers by the server through the use of the Accept-CH
>>> response header."
>>> > Should that be clearer?
>>>
>>> Yes, I think it is better.
>>>
>>> ---
>>>
>>> Regards,
>>>
>>> Christer
>>>
>>>
___
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-iesg-nomcom-eligibility-2020-01

[Barry Leiba]

Thanks for your review, Ines.  Reasonable comments, and we'll consider
them as we go into IESG Evaluation.  (On comment 3, I'm just going to
make the necessary change myself, and remove the CREF, so it's moot.)

Barry

On Thu, Apr 30, 2020 at 8:35 AM Ines Robles via Datatracker
 wrote:
>
> Reviewer: Ines Robles
> 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-iesg-nomcom-eligibility-2020-01
> Reviewer: Ines Robles
> Review Date: 2020-04-30
> IETF LC End Date: 2020-04-30
> IESG Telechat date: Not scheduled for a telechat
>
> Summary:
>
> This document provides a one-time interpretation of the eligibility rules (BCP
> 10) that is required for the exceptional situation of the cancellation of the
> in-person IETF 107 meeting. This document only affects the seating of the
> 2020-2021 NomCom and any rules that relate to NomCom eligibility or process
> before IETF 108, and does not set a precedent for the future.
>
> The document is clear and well written. Please find some comments below.
>
> Major issues: Not found
> Minor issues: Not found
> Nits/editorial comments:
>
> Some comments/questions:
>
> 1- It would be nice to add a reference here
>
> Section 1:
>
> "...resulting in its conversion to a limited-agenda virtual meeting, with 
> remote
>participation only.":
>
>e.g. [IETF 107 Virtual] =
>
> https://mailarchive.ietf.org/arch/msg/ietf-announce/Gqc4-GIsnvccObQrrciL_Vm0HMU/
>
> 2- Should this clarification be added?
>
> " ...before IETF 108..." --> "...before IETF 108 (virtual or in-person
> meeting)..." e.g. in the introduction or in section 3.
>
> 3- Related to this comment
> [https://mailarchive.ietf.org/arch/msg/ietf/kHVPn0tyF5o4Rvd3aZ51JA2MDtU/]
>
> "... In section 2, last paragraph, I suggest changing the CREF to, "Note: The
> previous two sentences will be replaced before publication with, 'This 
> document
> contains the outcome of that discussion.'"
>
>   Should this suggestion be applied?
>
>   Note that CREF2 mentions "the previous sentence", not "the previous two
>   sentences"
>
> 4- It would be nice to add a reference to eligibility-discuss mailing list/
> draft-carpenter-eligibility-expand
>
> Section 3:
>
> "...as there will be time for proper community work on such an update..."
>
> Thus, e.g. "...community work on such an update (e.g. efforts such as
> [Eligibility-discuss-ml] and [Eligibility-criteria])"
>
> [Eligibility-discuss-ml]=
> https://mailarchive.ietf.org/arch/browse/eligibility-discuss/
> [Eligibility-criteria]=
> https://datatracker.ietf.org/doc/draft-carpenter-eligibility-expand/
>
> Thank you for this document,
>
> Ines.
>
>
>

___
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-gellens-lost-validation-05

[Barry Leiba]

Thanks, Pete, for a very helpful review.

Barry

On Sat, Mar 7, 2020 at 11:52 AM Pete Resnick via Datatracker <
nore...@ietf.org> wrote:

> Reviewer: Pete Resnick
> Review result: Not 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-gellens-lost-validation-05
> Reviewer: Pete Resnick
> Review Date: 2020-03-07
> IETF LC End Date: 2020-03-31
> IESG Telechat date: Not scheduled for a telechat
>
> Summary:
>
> Abstract, Scope, and Introduction do not accurately reflect the content of
> the
> document, which is not simply a registration.
>
> Major issues:
>
> The Abstract and sections 1 & 2 (Scope and Introduction) indicate that this
> document is simply an IANA registration of an S-NAPTR Application Service
> Tag.
> However, section 3 is quite clearly new protocol, some of which changes
> how RFC
> 5222 implementations should operate if used in a particular context, and
> section 4 lays out the backward compatibility of this new protocol with
> legacy
> RFC 5222 implementations. There is the implication that the NENA i3
> documents
> will actually be the home of that protocol, but the current i3 document
> referenced here does not do so, making this document the canonical
> statement of
> the protocol operations necessary to implement the i3 architecture. That
> doesn't seem appropriate for an Informational document that purports to
> simply
> be a registration.
>
> At the very least, the Abstract, Scope, and Intro would need to be updated
> to
> reflect the actual contents of the document. I think things would be better
> served by making this a Proposed Standard document so that it gets the
> appropriate level of review. I understand from the Shepherd writeup that
> the
> ECRIT WG doesn't have the energy to really work on this document. However,
> this
> is a simple enough extension to the LoST protocol that I think it's
> unproblematic to have it as an AD-sponsored standards track document.
>
>
>
>
___
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

[Barry Leiba]

Robert, thanks for the careful (as always) review.

Just on one point -- the authors can reply to the others:

> It doesn't look like application/jscalendar+json has had a media type review.

There aren't formal media-type reviews for types registered in
IETF-consensus documents: see Section 3.1 of RFC 6838.

That said, Section 5.1 of 6838 says this:

   Notice of a potential media type registration in the standards tree
   SHOULD be sent to the media-ty...@iana.org mailing list for review.
   This mailing list has been established for the purpose of reviewing
   proposed media and access types.

I strongly encourage the authors to follow the advice in that section
now: it's not too late.  And I'm sorry that I didn't catch that
myself; thanks for picking it up.

Barry

___
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-dnsop-7706bis-07

[Barry Leiba]

Thanks, Ace, and post the update whenever you’re ready.

Barry

On Fri, Feb 28, 2020 at 10:18 AM Warren Kumari  wrote:

> On Fri, Feb 28, 2020 at 8:02 AM Ines Robles via Datatracker
>  wrote:
> >
> > Reviewer: Ines Robles
> > 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-dnsop-7706bis-07
> > Reviewer: Ines Robles
> > Review Date: 2020-02-28
> > IETF LC End Date: 2020-02-28
> > IESG Telechat date: Not scheduled for a telechat
> >
> > Summary:
> >
> > The document is well written,  it supplies appendixes with examples.
> >
> > This document describes a method for the operator of a recursive
> resolver to
> > have a complete root zone locally, and to hide queries for the root zone
> from
> > outsiders, at the cost of adding some operational fragility for the
> operator.
> >
> > I have some minor questions.
> >
> > Major issues: None
> >
> > Minor issues: None.
> >
> > Nits/editorial comments:
> >
>
> Thank you for the review!
>
> > 1- Appendix B.5: it seems that the link is not valid:  >resolver.readthedocs.io/en/stable/modules.html#root-on-loopback-rfc-
> >7706>
> >
> >   This link worked for me:
> >   https://knot-resolver.readthedocs.io/en/stable/modules-rfc7706.html.
>
> Thanks - not just for pointing out the issue, but also finding a
> better version - as suggested, I am changing this (in a git branch
> where I am collecting updates) to
> https://knot-resolver.readthedocs.io/en/v5.0.1/modules-rfc7706.html -
> I believe that stability is the most important attribute. AD, please
> let us know if you disagree.
>
> >
> > Questions:
> >
> > 1- It seems that this document replaces RFC7706, but the document states
> that
> > it updates RFC7706, is that correct?
>
> Oh, good point - once this is published, it does replace 7706 (it is a
> bis, and contains all of the content from 7706), so Obsoletes is
> better.
> Thank you, changed.
>
> >
> > 2- Abstract: "The cost of adding some operational fragility for the
> operator",
> > Does it introduce security considerations that have to be mentioned?
> >
> > 3- Section 1: "Research shows that the vast majority of queries going to
> the
> > root are for names that do not exist in the
> >root zone." - Do you have some references to that research that can
> be added
> >to the draft?
>
> H... I think that we missed this because, within the DNS community
> this is sufficiently well known that we don't even think about /
> question it.
> There is quite a lot of research on this, but much if it is behind
> paywalls - while almost 20 years old now (Gods, I feel old!), I think
> that the best one to cite is still:
> https://www.caida.org/publications/papers/2001/DNSMeasRoot/dmr.pdf (
> DNS Measurements at a Root Server ) -- I will add this.
>
> >
> > 4- I would expand KSK to Key signing key (KSK).
>
> Thanks! Done!
>
> >
> > 5- Should this draft add a reference to rfc8499?
>
> Seems like a good idea, thanks! I'm adding:
> "Readers are expected to be familiar with ."
>
> >
> > Thank you for this document,
>
> ... and thank you for the review.
>
> W
>
> >
> > Ines.
> >
> >
>
>
> --
> I don't think the execution is relevant when it was obviously a bad
> idea in the first place.
> This is like putting rabid weasels in your pants, and later expressing
> regret at having chosen those particular rabid weasels and that pair
> of pants.
>---maf
>
___
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-dnsop-7706bis-07

[Barry Leiba]

Thanks for the review, Ines.

Barry

On Fri, Feb 28, 2020 at 5:02 AM Ines Robles via Datatracker <
nore...@ietf.org> wrote:

> Reviewer: Ines Robles
> 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-dnsop-7706bis-07
> Reviewer: Ines Robles
> Review Date: 2020-02-28
> IETF LC End Date: 2020-02-28
> IESG Telechat date: Not scheduled for a telechat
>
> Summary:
>
> The document is well written,  it supplies appendixes with examples.
>
> This document describes a method for the operator of a recursive resolver
> to
> have a complete root zone locally, and to hide queries for the root zone
> from
> outsiders, at the cost of adding some operational fragility for the
> operator.
>
> I have some minor questions.
>
> Major issues: None
>
> Minor issues: None.
>
> Nits/editorial comments:
>
> 1- Appendix B.5: it seems that the link is not valid: resolver.readthedocs.io/en/stable/modules.html#root-on-loopback-rfc-
>7706>
>
>   This link worked for me:
>   https://knot-resolver.readthedocs.io/en/stable/modules-rfc7706.html.
>
> Questions:
>
> 1- It seems that this document replaces RFC7706, but the document states
> that
> it updates RFC7706, is that correct?
>
> 2- Abstract: "The cost of adding some operational fragility for the
> operator",
> Does it introduce security considerations that have to be mentioned?
>
> 3- Section 1: "Research shows that the vast majority of queries going to
> the
> root are for names that do not exist in the
>root zone." - Do you have some references to that research that can be
> added
>to the draft?
>
> 4- I would expand KSK to Key signing key (KSK).
>
> 5- Should this draft add a reference to rfc8499?
>
> Thank you for this document,
>
> Ines.
>
>
>
___
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-regext-data-escrow-04

[Barry Leiba]

Thanks for the review, Stewart.

Barry

On Fri, Feb 28, 2020 at 3:30 AM Stewart Bryant via Datatracker <
nore...@ietf.org> wrote:

> Reviewer: Stewart Bryant
> 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-regext-data-escrow-04
> Reviewer: Stewart Bryant
> Review Date: 2020-02-28
> IETF LC End Date: 2020-02-28
> IESG Telechat date: Not scheduled for a telechat
>
> Summary: A well written document ready for publication
>
> Major issues: None
>
> Minor issues: None
>
> Nits/editorial comments: None
>
>
>
>
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] [regext] Genart telechat review of draft-ietf-regext-bundling-registration-11

[Barry Leiba]

> If (for some reason) it does not gain rough consensus from the IETF as a 
> whole (and this
> seems to be an extreme corner case), then it could be published as an 
> individual RFC - but
> should be kicked back to the WG to make this decision.

Oh, yes, absolutely that: at the first cut, it will have to be the
working group that decides where to go from here.

Barry

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

Re: [Gen-art] [regext] Genart telechat review of draft-ietf-regext-bundling-registration-11

[Barry Leiba]

> If I think about it too much, I end up unable to parse the notion of a
> document published on the IETF stream without IETF rough consensus.

And yet they are there today and will continue to be.

b

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

Re: [Gen-art] [regext] Genart telechat review of draft-ietf-regext-bundling-registration-11

[Barry Leiba]

> If we do not have agreement on what the meaning is for the relevant
> terms, then either
> 1) The document should not be an IETF consensus document (which even
> Informational publication is)

Just a point on this: it's not true.

We have a "consensus" flag in the datatracker, which triggers a
boilerplate change.  It's always set to "yes" for Standards Track or
BCP, but for Informational and Experimental it can be set either way.
If it's set to "no", the boilerplate says that the document does not
have IETF consensus.  It's possible that when we're done with this
document it could settle into that.

It's also possible that we might convince the regext working group to
stop processing this document and suggest to the authors to go to the
ISE.  I don't think we're there yet, and at the moment the working
group has consensus to publish it as a working group product

Barry

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

Re: [Gen-art] [CDNi] I-D Action: draft-ietf-cdni-request-routing-extensions-07.txt

[Barry Leiba]

Thanks for the updates, Ori.  As we discussed, I will now re-run a
2-week last call purely to call out the new downref to RFC 7336, as we
moved 7336 to normative.  The document should be on the IESG telechat
on 17 Oct.

Barry

On Tue, Sep 24, 2019 at 10:00 AM Ori Finkelman (IETF)
 wrote:
>
> Hi All,
> This submission fixes the comments from all reviewers, I would like to thank 
> all reviewers for taking the time and sharing their comments.
> Please note the diff should be against revision 05 rather than 06 as most of 
> the changes were submitted in 06.
>
>
> Here is the full list of comments that were fixed in this version:
> =
>
> ****
> Reviewer: Barry Leiba (AD)
>
>
> 1. Please use the new BCP 14 boilerplate and references: see RFC 8174.
> >> fixed
>
> 2. Abstract vs Introduction:  The sentence about the SVA seems out of
> place in the Abstract, and is oddly missing from the Introduction.  I
> would add the first two sentences of the Abstract to the Introduction.
> Then remove the first sentence from the Abstract and also remove “In
> that aspect,” from the second sentence.
>
> >> fixed
>
> 3. RFC 6707 defines necessary terminology, so it probably should be
> normative.  I will note a downref in the last-call notice in
> anticipation of that.
> >> fixed
>
>
> ***
> Reviewer: Dan Romascanu (Genart)
>
> 1. Several non-obvious acronyms are not expanded: FCI, FQDN
> >> fixed and removed the ones not used
> 2. Section 3 - typo in the first paragraph '...the uCDN MUST be differnet ...'
> >> fixed
>
> *
> Reviewer: Zitao Wang (Opsdir)
>
> #1: There are a lot of abbreviations that are not provided with explanations 
> or
> citations, such as uCDN, dCDN, CFI, etc.
> >> fixed and remove the ones not necessary
>
> #2: The example of of a Redirect Target capability object serialization, is it
> encoded as json? Please present its encoding format.
> >> fixed
>
> #3: In section 2.1, the "Mandatory-to-Specify" attributes of dns-target and
> http-target, it describes that "No, but at least one of dns-target or
> http-target MUST be present and non-empty." I wonder whether there should be a
> detection mechanism. For example, if the requirements are not met, an error
> message will be returned. And if there are existing mechanisms, please briefly
> introduce them.
>
> >> That one is a great catch, thanks. I have changed it so it is not an error 
> >> anymore. Instead we have defined a default behavior for the case
> it is not present or empty, see the fixed draft.
>
> **
> Reviewer: Linda Dunbar (Secdir)
>
> The terminology RR (Request Router) and CP (Content Provider) specified by the
> Terminology are not used for the entire document. I assume that RR would be 
> the
> one request content, isn't? is RR same as Client?  Is RR part of Downstream 
> CDN
> Provider? is the CP same as Downstream CDN provider or Upstream CDN Provider?
>
> >> In the new version RR appears in a few locations. I have added more 
> >> explanations and references to the relevant CDNI docs where it was defined.
>
> who issued the Redirect Target?
>
> It would be good for the document to clearly specify the relationship of all
> the entities, such as who makes request and who respond, and who use the
> Redirect Target capability, etc.
>
> >> we have added drawings of sequences that explain it all, I hope it will be 
> >> clearer now.
>
> ***
> Reviewer: Michael Tüxen (Tsvart)
>
> To improve readability, you might want to
> * resolve acronyms on first occurence like CDN, CDNI,...
> >> fixed
> * Remove section 1.1, since the introduced abbreviations are not used in the 
> text.
> >> fixed
> * add a graphical representation of the involved nodes and the messages being 
> exchanged between them
> >> Added sequence diagrams sections for both extensions.
>
> Typos:
> * Section 3: the uCDN provide a fallback -> the uCDN provides a fallback
> * Section 6: Nir B.  Sopher -> Nir B. Sopher (no double space after period)
> * Section 6: Kevin J.  Ma -> Kevin J. Ma (no double space after period)
> >> fixed
>
> ***
> Reviewer: Ben Niven-Jenkins (CDNI)
>
> Is there a reason that IPv6 address

Re: [Gen-art] Genart last call review of draft-klensin-idna-unicode-review-02

[Barry Leiba]

Thanks, Joel, for taking the time to review this!

Barry

On Thu, Aug 8, 2019 at 10:23 PM Joel Halpern via Datatracker <
nore...@ietf.org> wrote:

> Reviewer: Joel Halpern
> 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-klensin-idna-unicode-review-02
> Reviewer: Joel Halpern
> Review Date: 2019-08-08
> IETF LC End Date: 2019-08-30
> IESG Telechat date: Not scheduled for a telechat
>
> Summary: THis document is ready for publication as a Proposed Standard
>
> This reviewer found the document quite readable and clear about what
> it was
> doing (with one minor issue noted below.)  The reviewer does not have
> the
> background to evaluate whether the technical substance is correct or
> incorrect, and leaves that to the community review.  The document is
> quite
> persuasive.
>
> Major issues: N/A
>
> Minor issues:
> I would like to see a little more explicit text in section 3.2.  It
> was not
> until I reached the IANA considerations (section 8) that I realized
> that
> section 3.2 intended to mandate that the IESG create and where
> applicable
> use a broad review team for the new code point review.  I think a
> sentence
> or so along the lines of "Creation of this team when needed is a new
> responsibility placed on the IESG by this document." would have helped.
>
> Nits/editorial comments: N/A
>
>
>
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART Telechat Call review of draft-ietf-extra-imap-fetch-preview-03

[Barry Leiba]

Thanks, Meral, for the review.

> Minor issues:
> -It may be obvious to most but it would be good to also mention how encrypted 
> email
> should be handle and what type of preview should be allowed if any

It's certainly easy to say something, and I'll leave it to the author
to decide whether to.  But, yes, it's obvious: if the mail is
encrypted, the server *can't* provide any meaningful preview.

One reason it might be useful to say something is that the end of
Section 3.2 makes a semantic distinction between a zero-length string
and NIL, so it might be useful to say which one is applicable to an
encrypted message.

Barry

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

Re: [Gen-art] Genart telechat review of draft-faltstrom-unicode11-08

[Barry Leiba]

(And I was still not sufficiently clear...)
The list for the expert to check is in the appendices.

Barry

On Mon, Mar 18, 2019 at 8:31 AM Barry Leiba  wrote:
>
> Hi, Dan.  Thanks for the review, and I’m sorry you didn’t get a response to 
> your question before.
>
> Last part first: IANA does not normally make changes until the document is 
> approved, and this is not an exception.
>
> The changes to the derived property values are described in detail in the 
> text in Section 3.  The designated expert will need to check all that and 
> generate a list of specific chaanges to the table here:
>
> https://www.iana.org/assignments/idna-tables-6.3.0/#idna-tables-properties
>
> ...and IANA will then apply those changes.
>
> Barry
>
> On Mon, Mar 18, 2019 at 3:31 AM Dan Romascanu via Datatracker 
>  wrote:
>>
>> Reviewer: Dan Romascanu
>> Review result: Ready with Issues
>>
>> 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 wait for direction from your
>> document shepherd or AD before posting a new version of the draft.
>>
>> For more information, please see the FAQ at
>>
>> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
>>
>> Document: draft-faltstrom-unicode11-08
>> Reviewer: Dan Romascanu
>> Review Date: 2019-03-18
>> IETF LC End Date: 2019-03-05
>> IESG Telechat date: Not scheduled for a telechat
>>
>> Summary:
>>
>> This document is Ready. However, I have signaled one minor issue in my LC
>> review which was not addressed in the revision, neither have I seen an answer
>> to the clarification that I requested (unless I missed some mail).
>>
>> Major issues:
>>
>> Minor issues:
>>
>> (from my previous review, not addressed)
>>
>> The IANA Considerations text is not clear to me.
>>
>> > IANA is requested to update the IDNA Parameters registry of derived
>>property values, after the expert reviewer validates that the derived
>>property values are calculated correctly.
>>
>> What does this exactly say? Are these recommendations for future actions, or 
>> do
>> they refer specifically to property values described in this document? Are 
>> the
>> expert reviewer validation and IDNA Parameters registry update required to be
>> performed prior to approval of this document?
>>
>> Nits/editorial comments:
>>
>>

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

Re: [Gen-art] Genart telechat review of draft-faltstrom-unicode11-08

[Barry Leiba]

Hi, Dan.  Thanks for the review, and I’m sorry you didn’t get a response to
your question before.

Last part first: IANA does not normally make changes until the document is
approved, and this is not an exception.

The changes to the derived property values are described in detail in the
text in Section 3.  The designated expert will need to check all that and
generate a list of specific chaanges to the table here:

https://www.iana.org/assignments/idna-tables-6.3.0/#idna-tables-properties

and IANA will then apply those changes.

Barry

On Mon, Mar 18, 2019 at 3:31 AM Dan Romascanu via Datatracker <
nore...@ietf.org> wrote:

> Reviewer: Dan Romascanu
> Review result: Ready with Issues
>
> 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 wait for direction from your
> document shepherd or AD before posting a new version of the draft.
>
> For more information, please see the FAQ at
>
> .
>
> Document: draft-faltstrom-unicode11-08
> Reviewer: Dan Romascanu
> Review Date: 2019-03-18
> IETF LC End Date: 2019-03-05
> IESG Telechat date: Not scheduled for a telechat
>
> Summary:
>
> This document is Ready. However, I have signaled one minor issue in my LC
> review which was not addressed in the revision, neither have I seen an
> answer
> to the clarification that I requested (unless I missed some mail).
>
> Major issues:
>
> Minor issues:
>
> (from my previous review, not addressed)
>
> The IANA Considerations text is not clear to me.
>
> > IANA is requested to update the IDNA Parameters registry of derived
>property values, after the expert reviewer validates that the derived
>property values are calculated correctly.
>
> What does this exactly say? Are these recommendations for future actions,
> or do
> they refer specifically to property values described in this document? Are
> the
> expert reviewer validation and IDNA Parameters registry update required to
> be
> performed prior to approval of this document?
>
> Nits/editorial comments:
>
>
>
___
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-dmarc-eaiauth-03

[Barry Leiba]

Thanks for the review, Tim.

The html rendering issues are for the RFC editor to deal with, and not in
the scope of the draft editors.

Barry

On Tue, Mar 12, 2019 at 7:54 AM Tim Evens via Datatracker 
wrote:

> Reviewer: Tim Evens
> 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-dmarc-eaiauth-??
> Reviewer: Tim Evens
> Review Date: 2019-03-11
> IETF LC End Date: 2019-03-14
> IESG Telechat date: Not scheduled for a telechat
>
> Summary:
> Ready with nits.
>
> Major issues: None
>
> Minor issues: None
>
> Nits/editorial comments:
>
> Throughout the draft, section references (html rendering) does not
> correctly
> HREF the RFC and section.  For example, page-5 Section 6 has a reference to
> section 6.6.1 of RFC7489, but the HTML rendering HREF links to this draft
> instead of correctly linking to RFC7489 Section 6.6.1. Ideally the
> references
> should link correctly, for example on page-3 Section 4 with "Section 3 of
> [RFC7208]."
>
>
>
___
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-nottingham-rfc5785bis-08

[Barry Leiba]

> > [3] Naive question: do we want a statement about reserving/agreeing to never
> > allocate "example" in the .well-known space?
>
> Good question! I'm neutral on this; does anyone have strong feelings?

I wouldn't say my feelings are strong, but I think it's unnecessary.
The reason we have IP addresses and domain names set aside for example
use is that otherwise anything we put in documents might wind up in
actual use and result in nuisance traffic or worse.  If we publish an
example of .well-known in some document and decide to use "frobozz"
for the example, and "frobozz" some day winds up in actual use, what's
the harm.

Also, how useful is it to have exactly one example string?  Maybe we'd
need to assign anything that begins with "example-" as a reserved
string.  And then we're not far from "X-", and we know where that got
us.[RFC6648]

Barry

___
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-jmap-mail-14

[Barry Leiba]

Thanks, Dan, for taking time to review it!

Barry

On Fri, Feb 1, 2019 at 1:28 AM Dan Romascanu  wrote:

> Reviewer: Dan Romascanu
> 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-jmap-mail-??
> Reviewer: Dan Romascanu
> Review Date: 2019-01-31
> IETF LC End Date: 2019-02-04
> IESG Telechat date: Not scheduled for a telechat
>
> Summary:
>
> This is a clear and complete specification which is READY for publication
> from
> a Gen-ART perspective.
>
> Major issues:
>
> Minor issues:
>
> Nits/editorial comments:
>
>
>
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Genart telechat review of draft-ietf-dmarc-arc-protocol-21

[Barry Leiba]

Hi, Ines.  Thanks again for another review.

Barry

On Mon, Nov 19, 2018 at 3:52 PM Ines Robles
 wrote:
>
> Reviewer: Ines Robles
> 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 wait for direction from your
> document shepherd or AD before posting a new version of the draft.
>
> For more information, please see the FAQ at
>
> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
>
> Document: draft-ietf-dmarc-arc-protocol-21
> Reviewer: Ines Robles
> Review Date: 2018-11-19
> IETF LC End Date: 2018-11-06
> IESG Telechat date: 2018-11-21
>
> Summary:
>
> I believe the draft is technically good. This document is well written and
> clear to understand.
>
> This document describes the Authenticated Received Chain (ARC) protocol, which
> provides an authenticated "chain of custody" for a message, allowing each
> entity that handles the message to see what entities handled it before, and to
> see what the message's authentication assessment was at each step in the
> handling.
>
> I like that the document mentions the available implementations.
>
> Major issues: Not found
>
> Minor issues: Not found
>
> Nits/editorial comments:  Not found
>
>


-- 
Barry
--
Barry Leiba  (barryle...@computer.org)
http://internetmessagingtechnology.org/

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

Re: [Gen-art] [dmarc-ietf] Genart last call review of draft-ietf-dmarc-arc-protocol-18

[Barry Leiba]

> Nits/editorial comments:
>
> Page 18: “ptypes” →types
> Page 22: “concocted” → connected?

As Scott K says, "ptypes" is correct as written.

"Concocted" is also correct as written.

Barry

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

Re: [Gen-art] [Extra] Genart last call review of draft-ietf-extra-imap-list-myrights-05

[Barry Leiba]

> 3.  MYRIGHTS Return Option to LIST Command

>

>The ordering of the responses is significant only in that

>the server MUST NOT send a MYRIGHTS response for a given mailbox

>before it sends the LIST response for that mailbox.

>

> It's clear what this means, but I think the wording is not quite

> correct.


I don’t understand why you think it’s wrong as it is.  I think it’s fine
(well, it’s my text, actually, so of course I do) and don’t see the
problem.  While your suggestions are also OK, I don’t think any is better.


> (In regard to the substance of this constraint, it's not clear to me

> why it exists, but I assume that the authors know of a reason for it.)


The reason is that the client will be building a data structure of
mailboxes, and it’s possible that clients won’t be able to handle a
MYRIGHTS response when they have not built the mailbox entry from the
corresponding LIST response.  Another way to handle this would be to say
that clients MUST be able to do that, it’s very unlikely that a server
implementation would want to send them in the other order anyway, so it’s
easier to set the restriction there.

Barry
___
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-extra-specialuse-important-03

[Barry Leiba]

Thanks for the review, Brian.

> Thanks for making the reviewer's life so easy.

My pleasure.

> I wonder whether the special characters in the title will break
> some bibliographic software. Both $ and \ can have unexpected effects.

I think we have others with such characters, but I didn’t check.  In any
case, the RFC Editor staff will know, and we’ll deal with it in AUTH48.

Barry


-- 
Barry
--
Barry Leiba  (barryle...@computer.org)
http://internetmessagingtechnology.org/
___
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-urnbis-ns-reg-transition-08

[Barry Leiba]

Thanks for the review, Joel!

Barry

On Thu, Jul 6, 2017 at 8:40 PM, Joel Halpern <j...@joelhalpern.com> 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
>
> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
>
> Document: draft-ietf-urnbis-ns-reg-transition-??
> Reviewer: Joel Halpern
> Review Date: 2017-07-06
> IETF LC End Date: 2017-07-17
> IESG Telechat date: Not scheduled for a telechat
>
> Summary: This document is ready for publication as a Proposed Standard RFC.
>
> Major issues: N/A
>
> Minor issues: N/A
>
> Nits/editorial comments: N/A
>
>



-- 
Barry
--
Barry Leiba  (barryle...@computer.org)
http://internetmessagingtechnology.org/

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

Re: [Gen-art] Review of draft-leiba-rfc2119-update-02

[Barry Leiba]

Thanks, Robert!

Barry

On Thu, Mar 9, 2017 at 5:03 PM, Robert Sparks <rjspa...@nostrum.com> wrote:
> Reviewer: Robert Sparks
> 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 wait for direction from your
> document shepherd or AD before posting a new version of the draft.
>
> For more information, please see the FAQ at
>
> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
>
> Document: draft-leiba-rfc2119-update-02
> Reviewer: Robert Sparks
> Review Date: 2017-03-09
> IETF LC End Date: 2017-03-09
> IESG Telechat date: 2017-03-16
>
> Summary: Ready for publication as part of BCP 14
>
>
>



-- 
Barry
--
Barry Leiba  (barryle...@computer.org)
http://internetmessagingtechnology.org/

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

Re: [Gen-art] Review of draft-leiba-rfc2119-update-01

[Barry Leiba]

Thanks, Robert, for the review.

Barry

On Mon, Feb 13, 2017 at 4:42 PM, Robert Sparks  wrote:
> Reviewer: Robert Sparks
> 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-leiba-rfc2119-update-01
> Reviewer: Robert Sparks
> Review Date: 2017-02-13
> IETF LC End Date: 2017-03-09
> IESG Telechat date: Not scheduled for a telechat
>
> Summary: Ready for publication as part of BCP 14.
>
> I personally find the first bullet in the NEW section to be chatty,
> and think it could be reduced while strengthening the message, but
> enough eyes have been on this that I don't object to it going through
> as is.
>
> Major issues:
>
> Minor issues:
>
> Nits/editorial comments:
>
>

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

Re: [Gen-art] Gen-ART LC review of draft-leiba-3967upd-downref-00

[Barry Leiba]

Hi, Peter, and thanks for the review.

> Page 2, Section 2, 2nd paragraph, 1st sentence: change “case by case” to
> “case-by-case”.

I'm embarrassed by that, because I'm usually careful about it.  I
think I must have done some rephrasing (from "do it case by case" to
"do it on a case-by-case basis"), and neglected to add the hyphens.
They're now in my working version.

Barry

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

Re: [Gen-art] Gen-ART LC review of draft-leiba-cotton-iana-5226bis

[Barry Leiba]

> I think that there should be normative language to the IESG to verify 
> consistency

In principle, I agree with you, but there are practical considerations.

First, I'm pretty sure we don't have IETF consensus to say that
working groups MUST carefully consider the registration policies,
coordinate them among similar/related registries, and write
justifications for their decisions... and I think we'd have a hard
time getting consensus for that.  I think the document does the best
we can here, which is to explain why it's important, and to say that
this (English-word)should be done.

Second, few ADs have the interest in being rigorous about this, when
they consider the time spent looking at it, looking at other
registries, and arguing the point, and considering the other things
they're spending their time on (such as making sure the protocols
themselves are solid, that the security aspects are right, and so on).
When I was on the IESG, I did make a point of challenging working
groups on this point: please show me where the policy was discussed on
the mailing list, and please explain why you settled on Standards
Action, and why IETF Review or even Specification Required doesn't
work as well or better.  Sometimes that resulted in changes, and
sometimes it resulted in reasonable explanations and no change.  But
it took time to do that, and I think we can't expect it to happen in
general.

Third, while there is, as you point out, actual damage done by overly
strict policies (and I do point this out in the new text in the
document), the damage is limited and infrequent for the most part.  A
few times, we've run into major issues with very active registries
(media types and port numbers come to mind), and we've put out
extensive documents that corrected those situations.  But trying to
put MUSTs (whether they be capitalized or not) into a BCP to avoid
those is probably too much, and is not likely to get consensus.

Barry

>> -Original Message-
>> From: barryle...@gmail.com [mailto:barryle...@gmail.com] On Behalf Of
>> Barry Leiba
>> Sent: Tuesday, May 24, 2016 3:49 PM
>> To: Roni Even
>> Cc: General Area Review Team; draft-leiba-cotton-iana-
>> 5226bis@tools.ietf.org; IETF discussion list
>> Subject: Re: Gen-ART LC review of draft-leiba-cotton-iana-5226bis
>>
>> Hi, Roni, and thanks for the review.
>>
>> > I am wondering about the lack of normative language for example in
>> > section
>> > 4.11
>> >
>> >“When reviewing a document that asks IANA to create a new registry
>> > or change a registration policy to any policy more stringent than
>> > Expert Review or Specification Required, the IESG should ask for
>> > justification to ensure that more relaxed policies have been
>> > considered and that the strict policy is the right one.”
>> >
>> > Is the “should” normative here?
>>
>> Perhaps you're confusing "normative language" with "2119 key words":
>> text doesn't need 2119 key words for it to be normative, and this document
>> quite intentionally does not cite RFC 2119.
>>
>> The example you give is a perfect one to show why we're not trying to
>> shoehorn key words that were meant to give instructions for interoperable
>> protocols into a document that's giving advice for writing and interpreting
>> IANA Considerations.  The sentence above means exactly what it says in
>> English: it's advising the IESG, but it is ultimately the IESG's decision.
>>
>> Barry
>

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

Re: [Gen-art] Gen-ART LC review of draft-leiba-cotton-iana-5226bis

[Barry Leiba]

Hi, Roni, and thanks for the review.

> I am wondering about the lack of normative language for example in section
> 4.11
>
>“When reviewing a document that asks IANA to create a new registry or
> change a registration policy to any policy more stringent than Expert Review
> or Specification Required, the IESG should ask for justification to ensure
> that more relaxed policies have been considered and that the strict policy
> is the right one.”
>
> Is the “should” normative here?

Perhaps you're confusing "normative language" with "2119 key words":
text doesn't need 2119 key words for it to be normative, and this
document quite intentionally does not cite RFC 2119.

The example you give is a perfect one to show why we're not trying to
shoehorn key words that were meant to give instructions for
interoperable protocols into a document that's giving advice for
writing and interpreting IANA Considerations.  The sentence above
means exactly what it says in English: it's advising the IESG, but it
is ultimately the IESG's decision.

Barry

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

Re: [Gen-art] Gen-ART review of draft-campbell-art-rfc5727-update-03

[Barry Leiba]

Thanks for the review, Vijay.

Barry

On Fri, Apr 29, 2016 at 11:15 AM, Vijay K. Gurbani  wrote:
> I am the assigned Gen-ART reviewer for this draft. For background on
> Gen-ART, please see the FAQ at
> .
>
> Please resolve these comments along with any other Last Call comments
> you may receive.
>
> Document: draft-campbell-art-rfc5727-update-03
> Reviewer: Vijay K. Gurbani
> Review Date: Apr-29-2016
> IETF LC End Date: Not known
> IESG Telechat date: May-05-2016
>
> This document is ready as a BCP; it has addressed the only comment I
> had in -02 [1] review on Feb 26, 2016.  I have no further comments on
> this revision.
>
> Major: 0
> Minor: 0
> Nits: 0
>
> [1] http://www.ietf.org/mail-archive/web/gen-art/current/msg12972.html
>
> Thanks,
>
> - vijay
> --
> Vijay K. Gurbani, Bell Laboratories, Nokia Networks
> 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
> Email: vkg@{bell-labs.com,acm.org} / vijay.gurb...@nokia.com
> Web: http://ect.bell-labs.com/who/vkg/  | Calendar: http://goo.gl/x3Ogq
>
>

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

Re: [Gen-art] [urn] Review: draft-martin-urn-globus-02

[Barry Leiba]

What I'll say abut this, as responsible AD, is that the
almost-finished urnbis work has updated the registration procedure and
the registration template, and the "Namespace Considerations", along
with the requirement that it "outlines the perceived need for a new
namespace", is no longer there.  That update (see
draft-ietf-urnbis-rfc2141bis-urn, Section 6.4 and Appendix A) is not
yet finished and so isn't official, but the intent is clear and the
last call of this document has been posted to the urnbis working group
for review against the old+new requirements.

My view is that we should not be too rigorous about this point at this stage.

Barry

On Thu, Mar 17, 2016 at 5:15 AM, Jari Arkko  wrote:
> Thanks, Joel.
>
> Authors, any responses to this? I think we need to discuss this…
>
> Jari
>
> On 12 Feb 2016, at 00:26, Joel M. Halpern  wrote:
>
>> 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-martin-urn-globus-02
>>A URN Namespace for Globus
>> Reviewer: Joel M. Halpern
>> Review Date: 11-Feb-2016
>> IETF LC End Date: 9-March-2016
>> IESG Telechat date: 17-March-2016
>>
>> Summary: This document is nearly ready for publication as an informational 
>> RFC.
>>
>> This reviewer assumes that the appropriate message has been or will be sent 
>> to urn-...@apps.ietf.org.
>>
>> Major issues:
>>As per the pointer in this document to RFC 3406 section 4.3, this 
>> document is required to have a Namespace Considerations section which 
>> "outlines the perceived need for a new namespace (i.e., where existing 
>> namespaces fall short of the proposer's requirements)."  While there is a 
>> section called Namespace Considerations, what it lists is the envisioned 
>> usages, not the reasons existing name spaces are insufficient.
>>
>> Minor issues: N/A
>>
>> Nits/editorial comments: N/A
>>
>> ___
>> urn mailing list
>> u...@ietf.org
>> https://www.ietf.org/mailman/listinfo/urn
>

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

Re: [Gen-art] [urn] Review: draft-martin-urn-globus-02

[Barry Leiba]

> Thanks for your feedback. Speaking for Globus, we're open to making whatever
> changes the reviewers feel are necessary. If you'd be more comfortable with
> an extra line or two of justification in the "Namespace Considerations"
> section, we're happy to add that.

OK, then let's go ahead and add that extra line or two (Dale's
suggestion is a fine one), and then there's no controversy.

> If we do make revisions, does the review process have to start over? Or can
> we proceed from this stage after addressing concerns?

Oh, no, no need to start anything over.  You just add text (and have a
look at Stephen Farrell's comment also when you do that), post a
revised I-D, and we continue from where we are.

Barry

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

Re: [Gen-art] [urn] Review: draft-martin-urn-globus-02

[Barry Leiba]

In general, I completely agree with you on that.  That's why I didn't
say we should use the new process, but, rather, that on the particular
point you raise, we shouldn't be that rigorous right now.

b

On Thu, Mar 17, 2016 at 8:57 AM, Joel M. Halpern <j...@joelhalpern.com> wrote:
> I guess this is between Barry, Jari, and the IESG.
>
> If it were me, it would seem that a document using a new and
> not-yet-approved process would require a normative reference to the new
> process, and could not take effect until the new process was approved.
>
> Yours,
> Joel
>
>
> On 3/17/16 8:50 AM, Barry Leiba wrote:
>>
>> What I'll say abut this, as responsible AD, is that the
>> almost-finished urnbis work has updated the registration procedure and
>> the registration template, and the "Namespace Considerations", along
>> with the requirement that it "outlines the perceived need for a new
>> namespace", is no longer there.  That update (see
>> draft-ietf-urnbis-rfc2141bis-urn, Section 6.4 and Appendix A) is not
>> yet finished and so isn't official, but the intent is clear and the
>> last call of this document has been posted to the urnbis working group
>> for review against the old+new requirements.
>>
>> My view is that we should not be too rigorous about this point at this
>> stage.
>>
>> Barry
>>
>> On Thu, Mar 17, 2016 at 5:15 AM, Jari Arkko <jari.ar...@piuha.net> wrote:
>>>
>>> Thanks, Joel.
>>>
>>> Authors, any responses to this? I think we need to discuss this…
>>>
>>> Jari
>>>
>>> On 12 Feb 2016, at 00:26, Joel M. Halpern <j...@joelhalpern.com> wrote:
>>>
>>>> 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
>>>>
>>>> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
>>>>
>>>> Document: draft-martin-urn-globus-02
>>>> A URN Namespace for Globus
>>>> Reviewer: Joel M. Halpern
>>>> Review Date: 11-Feb-2016
>>>> IETF LC End Date: 9-March-2016
>>>> IESG Telechat date: 17-March-2016
>>>>
>>>> Summary: This document is nearly ready for publication as an
>>>> informational RFC.
>>>>
>>>> This reviewer assumes that the appropriate message has been or will be
>>>> sent to urn-...@apps.ietf.org.
>>>>
>>>> Major issues:
>>>> As per the pointer in this document to RFC 3406 section 4.3, this
>>>> document is required to have a Namespace Considerations section which
>>>> "outlines the perceived need for a new namespace (i.e., where existing
>>>> namespaces fall short of the proposer's requirements)."  While there is a
>>>> section called Namespace Considerations, what it lists is the envisioned
>>>> usages, not the reasons existing name spaces are insufficient.
>>>>
>>>> Minor issues: N/A
>>>>
>>>> Nits/editorial comments: N/A
>>>>
>>>> ___
>>>> urn mailing list
>>>> u...@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/urn
>>>
>>>
>>
>

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

Re: [Gen-art] FW: Gen-ART LC review of draft-ietf-imapapnd-appendlimit-extension-07

[Barry Leiba]

Hi, Peter, and thanks for the review.  I'm adding the working group
mailing list here, so they have a record of this.  My comments below.

> 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
> comment.  For background on Gen-ART, please see the FAQ at
> 
>
> Document: draft-ietf-imapapnd-appendlimit-extension-07
> Reviewer: Peter Yee
> Review Date: December 27, 2015
> IETF LC End Date: January 1, 2016
> IESG Telechat date: TBD
>
> Summary: This draft is basically ready for publication as a standards track
> RFC, but has nits that should be fixed before publication. [Ready with nits]
>
> The draft describes an extension to IMAP4v1 that allows a server to signal a
> maximum message upload size limit.
>
> Most of nits noted are linguistic, although there's a minor, repeated
> mistake in the ABNF that's critical to fix.
>
> Comments/Questions:
>
> Section 1, 2nd paragraph, 2nd sentence: the claim that this extension allows
> a server to avoid processing overly large messages (or attachments) is only
> true if a client implements and honors the extension.  A malicious client
> could still upload large messages and cause the server to process the
> message up to the point where it exceeds the server's limit.  While these
> overly large uploads would not be saved to disk, the server would still have
> to process them up to a point in order to determine that they should be
> discarded and a TOOBIG response returned.  Other mechanisms would be needed
> to fend off malicious clients that persist in such uploads.

Indeed; as with any IMAP extension, this helps only compliant
client-server combinations.  I think the Security Considerations
adequately covers the issue of a malicious client.

> Page 6, Section 6, 2nd full sentence: In light of the last paragraph of
> section 5 indicating that the number is a fixed maximum value, how would
> submitting a little too large message work?  Why is the server being lenient
> here?

The point is to warn against that sort of leniency.  One might think
that if you set a limit of, say, 2 MB, that you might act harshly to a
client that tries to post 6 MB, but not be so strict when a client
posts 2.1 MB.  The text warns that such leniency might be used to
enable an attack.

> Nits:

I noted in my AD review (posted to the imapext mailing list) that the
document is in need of a significant review for English corrections.
In discussion of that, we decided that the RFC Editor will have to
handle that: the authors have done a great job on this, but are not
native English writers, and we don't have natives at the ready to
help.

Authors, Peter has provided, below, a good list to help you with this.
If you can incorporate the changes he suggests, it'll help a lot, and
the RFC Editor can deal with any that remain.

One that I need to call out that's buried in Peter's list, the one he
mentions about ABNF (and this one is my fault, as I provided the
current version of ABNF and made the typo myself):

> Page 5, Section 5, ABNF: change "/=" to "=/" for the definitions of
> "capability", "status-att", and "status-att-val".

Yes.  I think I make that goof regularly.  Sigh.  Thanks for catching it.

Barry


> Page 1, Abstract, 1st sentence: change "mail" to "message".  Delete "of".
>
> Page 2, Section 1, 1st paragraph, 1st sentence: change "mail" to "message".
>
> Page 2, Section 1, 1st paragraph, 4th sentence: change "mail" to "message".
> Change "attachment" to "attachments".

Actually, make it "messages".

> Page 2, Section 1, 2nd paragraph, 1st sentence: insert "a" before "maximum".
> Insert "the" before "email".
>
> Page 2, Section 1, 2nd paragraph, 2nd sentence: change "server side" to
> "server-side".
>
> Page 3, Section 2, 1st paragraph, 1st sentence: insert "the" before the
> first "APPENDLIMIT".  Insert "the" before "authenticated".
>
> Page 3, Section 2, 1st paragraph, last sentence: insert "An" at the
> beginning of the sentence.
>
> Page 3, Section 2, 1st paragraph after (a), 1st sentence: delete "the"
> before "mailboxes".
>
> Page 3, Section 2, 1st paragraph after (a), 2nd sentence: insert "the"
> before "same".
>
> Page 3, Section 2, 3rd paragraph after (b), 1st sentence: insert "an" before
> "APPENDLIMIT".  Insert "a" before "STATUS".
>
> Page 3, Section 2, 3rd paragraph after (b), 2nd sentence: change "New" to "A
> new".  Change "mailbox specific" to "mailbox-specific".
>
> Page 3, Section 2, 3rd paragraph after (b), 3rd sentence: insert "to" before
> "section".  Insert "the" before "response".
>
> Page 3, Section 2, last paragraph, 1st sentence: insert "An" at the
> beginning of the sentence.  Delete "kind of".
>
> Page 3, Section 2, last paragraph, 2nd sentence: insert "a" before "client".
> Insert "the" before "advertised".
>
> Page 3, Section 

Re: [Gen-art] Gen-ART Last Call review of draft-blanchet-ccsds-urn-00

[Barry Leiba]

>
> Minor issues:
>
> to check with AD: the draft has expired and is listed as Information.
> Should new revision be listed as Informational ?
>

Hi, Meral.
I don't understand what you're asking here.  First, the draft is not
expired.  Second, I don't get what you're asking to be changed.

Can you explain further?

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

Re: [Gen-art] Gen-ART Last Call review of draft-blanchet-ccsds-urn-00

[Barry Leiba]

Hi, Meral.

>The draft expired Sept 7 I think [1]

Please use the datatracker:
https://datatracker.ietf.org/doc/draft-blanchet-ccsds-urn/

The draft's expiration date was 7 Sept, but it's in IESG processing,
so it remains active.

> but real issue I raised was if it
> should be reviewed as Informational draft or Standards draft?

Where do you see Standards Track anywhere?  Everything I see says
Informational, and that's what's intended.  So it should be reviewed
as Informational.  If anything says Standards Track, please point me
to it, because I'd need to make sure that was changed.

Barry

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

Re: [Gen-art] Gen-ART review of draft-ietf-hybi-permessage-compression

[Barry Leiba]

Hi, Dan, and thanks for the review.

 I do not know if this is an issue, but I am asking the question. Some
 implementations are mentioned in the write-up, but they seem to have been
 written and deployed based on very old versions of the document – 05 and
 earlier, dating three years back. I am wondering if this is a problem of the
 write-up not being updated. If not – have the changes brought to the
 document since draft-05 impacted the negotiation and algorithms described in
 the document?

The history here is that the working group sent the document to me at
version -05, and I reviewed it and sent it back for more editorial
work -- I found it very hard to read and often unclear.
Unfortunately, the editorial work took two years and many revisions to
complete, but I think the result is clear and easy to read, and I'm
happy with the result.  But that work did not make technical changes
to the protocol, so implementations of -05 are still implementations
of -22... unless, of course, they were based on any misunderstandings
of an unclear document.  I think the likelihood of that last is low,
because the implementors were involved in the development of the
document.

On the minor issues:
I'm ambivalent about changing the musts and must not to 2119 key
words.  I think you know that I'm not a fan of overuse of those key
words.  On the other hand, they do apply fine here as key words, and I
have no objection to changing them.  I'll leave that up to the author
and shepherd.

Nits 1 and 2 are correct, and should be fixed; thanks.  For nit 3, I'm
happy to have the acknowledgments section reflect the author's voice.

Barry

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

Re: [Gen-art] Gen-ART Review of draft-ietf-oauth-spop-11

[Barry Leiba]

 Major Concerns:

 What is the justification for having the plain verifier? If one is
 intercepted by a malicious application, your extension becomes pointless.

Yes, this is what my DISCUSS is about.  I'm glad to have support for that view.

 Is code_challenge_method missing in 4.5?

No.  The challenge method is set when the challenge is sent and
recorded (4.2), and not when the verifier is sent later.  If the
method was sent in 4.5, it would open a hole in the protocol (at least
as long as plain exists).

Barry

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

Re: [Gen-art] Gen-ART Review of draft-ietf-oauth-spop-11

[Barry Leiba]

 Is code_challenge_method missing in 4.5?

 No.  The challenge method is set when the challenge is sent and
 recorded (4.2), and not when the verifier is sent later.  If the
 method was sent in 4.5, it would open a hole in the protocol (at least
 as long as plain exists).

 But the document doesn't say that the code_challenge_method is embedded in
 the token somehow. Or did I miss it?

The challenge and the challenge method are given in 4.2, and both need
to be remembered by the server.  When the verifier is presented in
4.5, the server uses the remembered method to transform the verifier
into the challenge, and then compares it with the remembered
challenge.  We don't need nor want the method to be presented again at
that point, and because the client isn't doing the transform at that
step, it doesn't need to know the method.

Barry

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

Re: [Gen-art] Gen-ART Review of draft-ietf-oauth-spop-11

[Barry Leiba]

 In the majority of situations (the ones currently exploited) on iOS the
 attacker only has access to the response coming back from the
 AS and not the request with the code_challenge.  This is to do with
 the way custom scheme redirects work in the OS.

Ack; thanks for that explanation.

 The feedback was that there are some developers that would rather
 ignore the risk than do S256.

I find that curious, as it's very little code involved.

I'm still not certain that we should publish a standard protocol that
allows this weakness, rather than requiring that it be robust.

But I'll let my Sec AD colleagues weigh in, and will go with their
opinions on it.

Barry

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

Re: [Gen-art] Review: draft-klensin-smtp-521code-05.txt

[Barry Leiba]

 That wording works for me.

Yeh.

b

 On 3/17/15 10:21 AM, John C Klensin wrote:



 --On Monday, March 16, 2015 23:06 -0400 Barry Leiba
 barryle...@computer.org wrote:

 Joel, thanks for the review.

 Minor issues:
  The description of the 556 reply code in section 4 seems
  to switch between refering to the generating entity as a
 client and as a sesrver.  I presume this is because the
 actual sitaution is an SMTP server is trying to pass
 information onwards, and in that onwards direction it is a
 client which.  But it is still confusing for an SMTP client
 to make a determination and then an SMTP server which is
 apparently the same entity to generate the rror code to some
 other SMPT client.


 You're right about why, and you're right that it's confusing.
 I think the reader and the text would be better served by
 changing the first instance of the word client (in the
 second sentence) to server. Even though the server is acting
 as a client when it makes the determination that sentence is
 talking about, it's acting as a server in the sense that it
 will be returning a 556 to the client that it's serving.
 Calling it a client here only confuses things.


 Hi.  While I agree that the existing text is confusing (although
 correct), the suggested fix just substitutes one confusing
 arrangement for another, with server used twice in the same
 sentence to refer to two different hosts that serve two
 different roles.  See if the following rather more complete
 rewrite for that second sentence works better:

 When an intermediate SMTP system (typically a relay)
 that would normally attempt to open a mail connection to
 a host referred to in a forward-pointing address can
 determine that the host does not accept mail
 connections, and do so without attempting to open a
 connection to that target host, it is appropriate for it
 to return a reply with a 556 code to the system that
 sent it the message for outbound transmission.

 The eliminates the client and server terminology entirely
 and talks instead about actual functions.  I'm tired and there
 are probably better ways to stay that, but I think it is an
 improvement over both the existing text and the client - server
 patch.

 There is a case that the above doesn't cover, but neither does
 the original paragraph, and that is when a submission server
 (sic) encounters a nullMX record or equivalent on initial
 lookup.  When the submission server tries to do that, it is
 acting as an SMTP client, but the status of messages it returns
 to the submitting MUA is deliberately very flexible in the spec
 (see Section 3.2 of RFC 6409).

   john




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

Re: [Gen-art] Review: draft-klensin-smtp-521code-05.txt

[Barry Leiba]

Joel, thanks for the review.

 Minor issues:
 The description of the 556 reply code in section 4 seems to switch
 between refering to the generating entity as a client and as a sesrver.  I
 presume this is because the actual sitaution is an SMTP server is trying to
 pass information onwards, and in that onwards direction it is a client
 which.  But it is still confusing for an SMTP client to make a determination
 and then an SMTP server which is apparently the same entity to generate the
 rror code to some other SMPT client.

You're right about why, and you're right that it's confusing.  I think
the reader and the text would be better served by changing the first
instance of the word client (in the second sentence) to server.
Even though the server is acting as a client when it makes the
determination that sentence is talking about, it's acting as a server
in the sense that it will be returning a 556 to the client that it's
serving.  Calling it a client here only confuses things.

Barry

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

Re: [Gen-art] Gen-ART and OPS-Dir review of draft-ietf-json-text-sequence-09

[Barry Leiba]

Hi, David.  One note on your review:

 idnits didn't like the reference to RFC 20 for ASCII:

   ** Downref: Normative reference to an Unknown state RFC: RFC   20

 RFC 5234 (ABNF) uses this, which looks like a better reference:

[US-ASCII]  American National Standards Institute, Coded Character
Set -- 7-bit American Standard Code for Information
Interchange, ANSI X3.4, 1986.

Except that (1) many IETF documents do use RFC 20 and (2) the RFC 20
reference is not for ASCII: it's for RS, the Record Separator
character, which is explained in RFC 20, Section 5.2.

Barry

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

Re: [Gen-art] Gen-art telechat review: draft-mcdonald-ipps-uri-scheme-17

[Barry Leiba]

We'll get a revised draft.

Barry

On Thursday, December 4, 2014, Jari Arkko jari.ar...@piuha.net wrote:

 Many thanks of the review, Robert.

 Barry, Michael - re: (c) - will an update or an RFC Editor note be made
 about this?

 Jari


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

Re: [Gen-art] Gen-art telechat review: draft-mcdonald-ipps-uri-scheme-17

[Barry Leiba]

Hi, Robert, and thanks so much for the re-review.

 First: (For Barry as sponsoring AD and shepherd):

 I think you might want to say more about how this and the related PWG
 documents are being handled cross-organization.

 An RFC that normatively updates a document under some other organization's
 change control is an unusual thing. Usually there are parallel documents
 coordinating this. Is there such a parallel PWG doc this time?

 Why aren't there RFC variants of the PWG docs (we've republished other
 organization's documents in the RFC series before...)

When you suggest saying more, are you suggesting saying more in the document?

This document is updating and augmenting the earlier documents that
were published by the IPP working group, when it existed, and this
document is under IETF change control.  It does reference documents
from PWG, that's true, but I don't see anything remarkable about that:
we've done it often.  As the Permanent URI Schemes registry is Expert
Review, this could have been done through a PWG document, but the PWG
wanted IETF review of this document, and the document did benefit
greatly from that.  I think the right thing happened here, which is
why I AD-sponsored it.

Mostly, the reason the IETF isn't republishing the PWG documents is
that there's no current interest in the IETF for IPP, and the people
who care about IPP are over at PWG.  Getting a new, secure URI scheme
defined correctly was important, and we've done that.  But there
wouldn't be any real value in republishing the PWG documents.

Do you think we need to do/say more about this now?

 version 17 improves several aspects over 16, but there are still reference
 issues reported by idnits.
 The most important ones to fix are the Missing Reference issues it calls
 out.

All of the missing references are only notes in the change log
section.  They don't apply to the document now, and the section will
be removed by the RFC Editor.

There are two reference notes that still apply:

   -- Possible downref: Non-RFC (?) normative reference: ref. 'ASCII'

That's to the ANSI spec for ASCII, and is fine.

   -- Obsolete informational reference (is this intentional?): RFC 2566
  (Obsoleted by RFC 2911)

That is intentional; it's in the list of IPP versions, and is marked
in that list as obsolete.

Barry

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

Re: [Gen-art] Gen-art telechat review: draft-mcdonald-ipps-uri-scheme-17

[Barry Leiba]

 When you suggest saying more, are you suggesting saying more in the
 document?

 I mostly meant the writeup - I expect there will be IESG folks with the same
 questions I had.

I can do that, sure.

This document updates:
 ...
c) IEEE-ISTO PWG IPP Version 2.0 Second Edition [PWG5100.12], by
   extending section 4 'IPP Standards' and section 10 'Security
   Considerations'.

 This RFC-to-be is updating an IEEE-ISTO PWG document, and that seems
 exceptional enough to warrant mention about how the organizations
 are coordinating that update.

I'd think that's for PWG to address on their side, no?  If they accept
that they can have an IETF RFC formally updating one of their
documents, that's their process, not ours, no?

Barry

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

Re: [Gen-art] Gen-ART review of draft-murdock-nato-nid-02.txt

[Barry Leiba]

There will be a revised I-D.

Barry

On Tuesday, November 25, 2014, Jari Arkko jari.ar...@ericsson.com wrote:

 Thanks, Dan and Barry.

 Is there a new rev or RFC Editor -notes?

 On 20 Nov 2014, at 15:13, Romascanu, Dan (Dan) droma...@avaya.com
 javascript:; wrote:

  Hi Barry,
 
  This looks reasonable, thanks for the timely response and for addressing
 my comments. I suggest that the editor also fixes the text in section 7.
 
  Regards,
 
  Dan
 
 
  -Original Message-
  From: barryle...@gmail.com javascript:; [mailto:barryle...@gmail.com
 javascript:;] On Behalf Of
  Barry Leiba
  Sent: Wednesday, November 19, 2014 8:53 PM
  To: Romascanu, Dan (Dan)
  Cc: gen-art@ietf.org javascript:;;
 draft-murdock-nato-nid@tools.ietf.org javascript:;
  Subject: Re: Gen-ART review of draft-murdock-nato-nid-02.txt
 
  Thanks for the review, Dan.
 
  1.   The document does not expand the acronym NATO at the first
  occurrence. Moreover, in section 7 it mentions 'that a standards body,
  like NATO' which is misleading - as NATO is not a standards body. I
  suggest to use the full name in the title and abstract, expand the
  acronym at first occurrence and correct the text in Section 7.
 
  The AD/shepherd agrees.
 
  2.   The abstract and introduction should make clear that this is a
  request made according to RFC 3406 for a formal URN space type, as
  described in Section 4.3 of RFC 3406.
 
  I suppose that I agree with that, too, though I think it's less
 important.  But
  something like this should do nicely:
 
  OLD
This document describes a Uniform Resource Name (URN) namespace for
assignment by NATO.  The current primary use is for uniquely
identifying Extensible Markup Language (XML) artifacts that provide
information about NATO message text formats and service
specifications as described in various NATO standards [4],
instructions and publications.
 
  NEW
This document allocates a formal Uniform Resource Name (URN)
namespace for assignment by the North Atlantic Treaty Organization
(NATO), as specified in RFC 3406.  The current primary use is for
uniquely identifying Extensible Markup Language (XML) artifacts
that provide information about NATO message text formats and
service specifications as described in various NATO standards,
instructions and publications.
 
  END
 
  (That also removes the reference ([4]) in the abstract, as the RFC
 Editor
  doesn't allow references in abstracts.)  And then a similar change in
 the
  Introduction section.
 
  I could not find in the summary written by the AD shepherd an
  indication whether this review occurred.
 
  The AD/shepherd apologises profusely for his typo: the writeup said
 uri-
  review, where it should have said urn-nid.  I've corrected the error
 in the
  writeup, and, yes, the review happened.
 
  Ira, I'm going to move the document into IESG Evaluation state now.
  Please update the I-D as soon as you can with the above minor changes.
  Thanks.
 
  Barry
 
  ___
  Gen-art mailing list
  Gen-art@ietf.org javascript:;
  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] Gen-ART review of draft-murdock-nato-nid-02.txt

[Barry Leiba]

Thanks for the review, Dan.

 1.   The document does not expand the acronym NATO at the first
 occurrence. Moreover, in section 7 it mentions 'that a standards body, like
 NATO' which is misleading - as NATO is not a standards body. I suggest to
 use the full name in the title and abstract, expand the acronym at first
 occurrence and correct the text in Section 7.

The AD/shepherd agrees.

 2.   The abstract and introduction should make clear that this is a
 request made according to RFC 3406 for a formal URN space type, as described
 in Section 4.3 of RFC 3406.

I suppose that I agree with that, too, though I think it's less
important.  But something like this should do nicely:

OLD
   This document describes a Uniform Resource Name (URN) namespace for
   assignment by NATO.  The current primary use is for uniquely
   identifying Extensible Markup Language (XML) artifacts that provide
   information about NATO message text formats and service
   specifications as described in various NATO standards [4],
   instructions and publications.

NEW
   This document allocates a formal Uniform Resource Name (URN)
   namespace for assignment by the North Atlantic Treaty Organization
   (NATO), as specified in RFC 3406.  The current primary use is for
   uniquely identifying Extensible Markup Language (XML) artifacts
   that provide information about NATO message text formats and
   service specifications as described in various NATO standards,
   instructions and publications.

END

(That also removes the reference ([4]) in the abstract, as the RFC
Editor doesn't allow references in abstracts.)  And then a similar
change in the Introduction section.

 I could not find in the summary written by the AD shepherd an indication
 whether this review occurred.

The AD/shepherd apologises profusely for his typo: the writeup said
uri-review, where it should have said urn-nid.  I've corrected the
error in the writeup, and, yes, the review happened.

Ira, I'm going to move the document into IESG Evaluation state now.
Please update the I-D as soon as you can with the above minor changes.
Thanks.

Barry

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

Re: [Gen-art] Gen-ART LC review of draft-leiba-cotton-iana-5226bis

[Barry Leiba]

Thanks for the review, Roni.

 Section 2.3 discusses the issue of defining appropriate registration
 policy. I was wondering about consistency between the policies of similar
 registries, is it important and how to verify it. For example the policy
 for
 http://www.iana.org/assignments/sdp-security-descriptions/sdp-security-descriptions.xhtml#sdp-security-descriptions-3
 is standard action and for
 http://www.iana.org/assignments/srtp-protection/srtp-protection.xhtml#srtp-protection-1
 is specification required. I think that such cases should be discussed when
 defining the registration policy.


The policies do, indeed, need to be thought out when the documents are
developed, and I think 5226bis is clear about that.  But those decisions
have to be made by those developing the documents, and I don't know what
more we can say here about it, beyond what's here.

Do you have any specific suggestions?

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

Re: [Gen-art] Gen-ART LC review of draft-leiba-cotton-iana-5226bis

[Barry Leiba]

 I think that this is a point that should be made for anyone that needs to
 specify the registration policy. My feeling is that when the document is
 develop the focus is on the specified registry without looking at similar
 ones. Maybe the document should suggest that the IESG or document shepherd
 will try to verify that consistency was checked.


I'm very wary of suggesting that people copy registration policies from one
registry to another.  Mindless consistency between related registries in
specifically a non-goal here: the important point is that the policy for
each registry should be selected with though, and should apply to the needs
of *that* registry, even if that makes related registries differ.  I think
the document is clear about that.

We get ourselves in trouble when a batch of registries are all given the
same policy, and that policy turns out to be right for some and wrong for
others.

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

Re: [Gen-art] Gen-ART Last Call review of draft-nottingham-safe-hint-05

[Barry Leiba]

Thanks for the review, Brian.  Yes, Mark will tweak the IANA section after
last call.

There are plenty of sites that offer content that can be trimmed to be
safer.  Search engines can use it to filter what they return.  Video
sites can use it to not serve up R rated content.  And so on.

There is already some deployment.  Whether it gets widely deployed is
something we'll have to see.

Barry

On Thursday, October 23, 2014, Brian E Carpenter 
brian.e.carpen...@gmail.com wrote:

 I am the assigned Gen-ART reviewer for this draft. For background on
 Gen-ART, please see the FAQ at
 http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq.

 Please resolve these comments along with any other Last Call comments
 you may receive.

 Document: draft-nottingham-safe-hint-05.txt
 Reviewer: Brian Carpenter
 Review Date: 2014-10-24
 IETF LC End Date: 2014-11-18
 IESG Telechat date:

 Summary:   Almost ready
 

 Comment:
 

 I have no technical comments. I have not been reading the IETF Last Call
 thread, but
 my opinion fwiw is that this a figleaf that will provide no real
 protection.
 Undesirable sites will simply ignore it. Safe sites don't need it.

 Minor issues:
 -

 As the writeup says: The IANA Considerations section is a bit sparse.
 It should at least name the registry it's updating for convenience of the
 reader.

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

Re: [Gen-art] [abnf-discuss] Gen-ART Last Call review of draft-kyzivat-case-sensitive-abnf-01

[Barry Leiba]

Wow.  I'm replying to the version of this that went to abnf-discuss,
proving that it went there (see the appendage at the bottom).  But you're
right, Brian, that the list's archive is not working: the only message in
the archive is the one announcing the creation of the list.  My personal
archive of it has many messages.

I will contact Ietf-action about that now.  And thanks for the review, and
catching the typos.

Barry

On Saturday, September 6, 2014, Brian E Carpenter 
brian.e.carpen...@gmail.com wrote:

 I am the assigned Gen-ART reviewer for this draft. For background on
 Gen-ART, please see the FAQ at
 http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq.

 Please resolve these comments along with any other Last Call comments
 you may receive.

 Document: draft-kyzivat-case-sensitive-abnf-01.txt
 Reviewer: Brian Carpenter
 Review Date: 2014-09-06
 IETF LC End Date: 2014-09-30
 IESG Telechat date:

 Summary:   Ready with nits
 

 Comment:
 

 The writeup says this draft was discussed on the abnf-discuss list. When
 I looked,
 the mail archive for abnf-disc...@ietf.org javascript:; hadn't been
 updated since May 2012. Is there
 some other list?

 Nits:
 -

  Abstract
 
This document extends the base definition of ABNF (Augmented Mackus-
Naur Form)

 s/Mackus/Backus/

  1. Introduction
 
The base definition of ABNF (Augmented Mackus-Naur Form) supports
ASCII string literals.

 s/Mackus/Backus/



 ___
 abnf-discuss mailing list
 abnf-disc...@ietf.org javascript:;
 https://www.ietf.org/mailman/listinfo/abnf-discuss

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

Re: [Gen-art] Gen-ART and OPS-Dir review of draft-ietf-appsawg-nullmx-08

[Barry Leiba]

Thanks, David, for the re-review.

 A draft has just been
 submitted to replace RFC 1846 (Experimental) with a Standards Track RFC:

 https://datatracker.ietf.org/doc/draft-klensin-rfc1846bis/

 The IESG should decide whether to proceed with the downref to RFC 1846bis
 vs. publish the 1846bis draft as a standards track RFC and reference it.
 That decision is the open issue in this review of the nullmx draft.

Right, and the decision has already been made, which is why the second
last-call notice says that the document has been tentatively
approved:
The plan is to put the nullmx draft into the RFC Editor queue.  If we
can do the 1846bis processing quickly, so that when AUTH48 comes for
nullmx we see 1846bis as being essentially done, we will hold nullmx,
process the two documents together, and change the reference.  But if
it looks like 1846bis is getting hung up, we will proceed with
publication of nullmx with the downref.

That plan was discussed on the apps-discuss list a couple of weeks ago.

Barry

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

Re: [Gen-art] Gen-ART LC Review of draft-ietf-core-groupcomm-21

[Barry Leiba]

Hi, Ben, and thanks for the review.  Did you send it to the dime
list by accident, instead of to the core list?  In any case, would
you please re-send it to include the core list (along with the other
addresses as well, so that reply-all works)?  Thanks.

Barry


On Thu, Aug 14, 2014 at 4:20 PM, Ben Campbell b...@nostrum.com wrote:
 I am the assigned Gen-ART reviewer for this draft. For background on
 Gen-ART, please see the FAQ at

 http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq.

 Please resolve these comments along with any other Last Call comments
 you may receive.

 Document: draft-ietf-core-groupcomm-21
 Reviewer: Ben Campbell
 Review Date: 2014-08-14
 IETF LC End Date: 2014-08-14
 IESG Telechat date:

 Summary: This draft is not ready for publication as an informational RFC. It 
 has some significant issues, detailed below.

  Major issues:

 -- The draft contains significant material that I do not believe is 
 appropriate for an informational RFC, at least without some clear 
 explanations about why it appears. It purports to clarify the normative stuff 
 in RFC 7252 concerning multicast, but it does quite a bit more than that.

 Section 2.7 defines protocol, in the form of a RESTful methods and attributes 
 to manage multicast group membership.I agree in some cases it makes sense for 
 an informational RFC to define protocol. A common example is when we want to 
 document a proprietary protocol for some reason. As written, this does not 
 seem to fall unto such a case. If the authors and working group believe it 
 does, it would be helpful to add text explaining that, and how the reader 
 should interpret the section. (I recognize that this interface is 
 optional--but I don't think making it optional changes whether it should be 
 standards track.)

 In addition to that, the draft contains quite a bit of guidance that might be 
 more appropriate BCP. For example, there is guidance here where not following 
 it might do harm to the network. Additionally, I don't see how anyone could 
 expect to achieve interoperability the multicast features of RFC 7252 without 
 understanding this draft.  (I have to wonder why RFC 7252 did not have a 
 normative dependency on this draft.)

 -- The security aspects of group CoAP are pretty bad. To its credit, the 
 draft does a pretty good job of calling that out, and that work is in 
 progress to improve it. But I have to wonder if we would be better off not 
 encouraging multicast CoAP at all until such improvements are available. 
 Section 5.3 calls out some reasonable examples of mitigation approaches, but 
 I am a little concerned at the guidance that one should worry about these for 
 sensitive or safety-critical data. People are not good at knowing what 
 data is sensitive until it gets used against them. I think this is 
 especially true for IoT applications where we have less deployment experience.

 Along those lines, the Pervasive Monitoring Considerations section (kudos for 
 having one, btw), tries to balance application needs vs protecting 
 information. But the smart-grid example seems to be a case where the two are 
 really at odds. I am afraid people will interpret this along the lines of 
 well, the smart-grid application requirements force me to send unprotected 
 data all over the place, when I think the right answer is Group CoAP should 
 not be used for this sort of application until we can protect the data.




  Minor issues:

 -- 2.2, 5th paragraph: For sending nodes, it is recommended to use the IP 
 multicast address literal in a group URI.

 Can you elaborate on why? I can guess, but anytime we suggest using literal 
 IP addresses rather than DNS names, it's worth elaborating.

 -- 2.4:  ... if the resource being POSTed to has been designed to cope with 
 the unreliable and lossy nature of IP multicast.

 Can you elaborate on what it means to be designed to cope...? (Or reference 
 something that does?)

 -- 2.6:

 I think the Resource Directory reference needs to be normative.  (I see the 
 discussion of this from Barry's AD review, where the authors argued that the 
 reference is optional for implementations. But our definition of normative 
 references also includes things necessary to fully understand this draft. 
 Fully understanding even optional features is part of that.)

 -- 2.7.1, 2nd paragraph:

 Does this imply a need to coordinate pre-configured group addresses to avoid 
 collisions?

 -- 2.7.2.1: 2nd 2 last paragraph:

 Are there any scenarios where a missing port might be determined from DNS, 
 rather than just assuming the default?

 -- 2.7.2.6, 1st paragraph: This operation MUST only be used to delete or 
 update group membership objects for which the CoAP client, invoking this 
 operation, is responsible

 Do I understand correctly that this replaces the entire set? Is it possible 
 for two different clients to be responsible for two different subsets? If so, 
 how?

 -- 2.8 and (especially) 2.9:

 

Re: [Gen-art] Gen-art LC review of draft-ietf-mmusic-latching-05

[Barry Leiba]

 I was thinking of addressing them all in bulk once all the IESG
 comments were in. Apologies if that's considered a poor practice. I'll
 try to respond to all of them today.

We generally hold document updates and batch them (though that varies
too), but individual responses, sooner, is usually best.

Barry

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

Re: [Gen-art] Gen-art LC review of draft-ietf-mmusic-latching-05

[Barry Leiba]

 s8: Heresy Starts Barry Leiba in his comments in the tracker suggests
 that the references would be usefully split into Normative and
 Informative subsets.  Given the number of references, splitting them up
 seems like a good idea.  I am going to suggest something highly
 heretical:  Split them up but call them Key References and Additional
 References.  Normative has become such a loaded word in the standards
 community that, despite its underlying English meaning, it is probably
 better to confine its usage to Standards Track documents.  I feel that
 we usefully adopt this alternative classification for non-standards
 track documents as a general technique to avoid the ongoing discussions
 about split refetrence sections. Heresy Ends

That would address the spirit of my concern, and I'd be happy if we
went in that direction.

I think the RFC Editor would push back, as their Style Guide has an
effect on this as well... so if we do want to go in this direction, we
should head to rfc-interest and pose it as input to the updated RFC
Style Guide that they're working on.

Barry

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

Re: [Gen-art] [imapext] Gen-ART review of draft-ietf-qresync-rfc5162bis-09

[Barry Leiba]

 Actually, I think I convinced Barry that it is updating RFC 2683.

Yes: because the new line-length-limit recommendation is meant to
apply whether or not condstore or qresync are in play, this updates
remains (it's the others that used to be there that we scrubbed).

I think David's right that some version of what Eliot said:

 there
 is a requirement for strict syntax parsing.  If the client blows it in
 any way, the server SHOULD return an error with a BAD response.

...should be added to the section about the line-length limit.  A
sentence or two should do nicely.

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

Re: [Gen-art] Gen-ART LC Review of draft-leiba-smime-type-registry-02

[Barry Leiba]

Hi, Ben, and thanks for the review.

 -- It might be helpful to include the URL of the parent registry. I assume
 it's intended to be http://www.iana.org/assignments/media-types ?

Normally, I would be that specific.  But IANA are *SO* familiar with
the media-types registry that there's no possibility of confusion
here.

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

Re: [Gen-art] Gen-art review of draft-ietf-httpbis-method-registrations-14

[Barry Leiba]

   -- The document seems to lack a disclaimer for pre-RFC5378 work, but may
  have content which was first submitted before 10 November 2008.  If you
  have contacted all the original authors and they are all willing to 
 grant
  the BCP78 rights to the IETF Trust, then this is fine, and you can 
 ignore
  this comment.  If not, you may need to add the pre-RFC5378 disclaimer.
  (See the Legal Provisions document at
  http://trustee.ietf.org/license-info for more information.)

 No, it doesn't (why does idnits think so?)

Oh, geez, you really want to know?

Look at the history of the document:
- Up through version -02, it was marked as updates httpbis part 2.
- httpbis part 2 version -00 was posted before RFC 5378.
- The current version of httpbis part 2 does not include all the
authors that were included in the -00 version.

Through some combination of that history, it's possible that this
document has text from httpbis part 2 version -00, and that not all
the original authors have signed off on that.

So idnits is just raising a flag.  As it says, if this isn't a
problem, then it isn't a problem.  Kathleen was just pointing out that
idnits raised the flag, and asked you to check.

You checked.  All is well.  (We all have to remember that idnits is
only a tool)

   ** Obsolete normative reference: RFC 2068 (Obsoleted by RFC 2616)

 RFC 2068 currently is the only document that defines LINK/UNLINK. The only
 thing we can do here is to declare all references in the registrations to be
 informative, but I really really don't see why it would matter here.

Again, only a tool.  This is not an issue.  We have references to
obsolete documents periodically, and that's fine.  This is fine.  On
the other hand, we have many occasions where documents become obsolete
after they're put in as references, so it's good to check.

Again, you checked, and all is well.  No need to wrap ourselves around
that further.

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

Re: [Gen-art] Gen-ART review of draft-ietf-appsawg-malformed-mail-09

[Barry Leiba]

 Sections 7.1.* offers degrees of advice qualified by safely, usually,
 reasonably and should.  There appear to be only two concepts:
 - safely: Do this all the time.
 - usually, reasonably, should: This is the recommended course
 of action, but there may be exceptions.
 While RFC 2119 is not intended for Informational documents, this is an
 example of the sort of sloppiness that RFC 2119 is intended to clean up.
 At the very least, the use of three words for essentially the same concept
 is poor form, and RFC 2119 can be used in an Informational document when
 appropriate caveats are provided in the terminology section that references
 it.


 Earlier versions of this draft looked roughly like an applicability
statement, and thus
 had RFC2119 language throughout.   We decided that, as you point  out,
it's mostly
 advice, and not a way of establishing a capability within Internet Mail,
which would
 be more like what an applicability statement is for.

 I'm thus inclined not to backtrack, but merely satisfy your At the very
least clause.

I'm more inclined to leave it alone:
This is not conformance language at all, and isn't meant to be.  It's mild
advice about how one might handle bad situations.  We could be consistent,
and pick one word.  Or we can leave the document less stilted and have it
read better.  We specifically don't *want* to be precise, here, about the
strength or *exact* meaning of the advising words.

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

Re: [Gen-art] Gen-art review of draft-ietf-weirds-rdap-sec-04

[Barry Leiba]

 (Barry and Pete may still track the down ref issue, if there's something not
 completely resolved yet.)

No, nothing left to do: the references in question all have become or
are becoming informative.

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

Re: [Gen-art] Gen-ART LC Review of draft-thornburgh-adobe-rtmfp-07

[Barry Leiba]

 you're not the first person to be confused by that construct. i will change 
 instances of
 MUST ONLY to is allowed only if (or similar) and remove the definition 
 for MUST
 ONLY from Section 1.2.

I think this is an excellent idea.  RFC 6919 aside (ahem), it's rarely
a good idea to try to define new 2119-ish key words.

Speaking of which (my comments after a bunch of quotes)...

 -- section 3.2: Multiple endpoints SHOULD NOT have the same identity.

 Why not MUST? Will things not break if two endpoints do have the same 
 identity?

 this should be It is RECOMMENDED that multiple endpoints not have the same
 identity.  if two endpoints have the same identity, then they will be 
 indistinguishable.
 this will not break RTMFP, but might confuse an application.  that being 
 said, there
 could potentially be reasons to have different endpoints with 
 indistinguishable identities
 and that potential should not be normatively prohibited.
...
 -- A test SHOULD comprise testing whether the certificates are identical.

 What if it doesn't?

 again, that SHOULD should be reworded to RECOMMENDED.
...
 -- 3.5.1.1.1, 3rd paragraph:

 What are the consequences of having a tag with less than 8 bytes of length?
 Is the SHOULD reasonable here?

 both of those SHOULDs should be RECOMMENDEDs.
...
 -- 3.6.2.3.2, 2nd paragraph: ...an implementation SHOULD encode a Next
 User Data chunk instead of a User Data chunk

 I'm not sure why this needs to be normative, as I assume its just normal
 behavior. But if it does need to be normative, why not a MUST?  Can the far
 endpoint reasonably handle things if the SHOULD is violated?

 this should be a RECOMMENDED.  the far end will work just fine if Next User
 Data is never used.

In RFC 2119, SHOULD and RECOMMENDED are synonymous (they're just
covering different parts of speech; they fit differently into
sentences).  Changing SHOULD to RECOMMENDED (and, of course,
rewording the sentences accordingly) doesn't affect Ben's comments on
the points.

MUST means that the protocol will not work properly unless you do
this.  You just have to, without fail.

SHOULD (and RECOMMENDED) is really only a *little* lighter: it
still means that the protocol requires that you do this, but that
there might be good reasons not to -- you have to fully understand
what will happen if you don't do this before you can consider not
doing it.

To my mind (and I consider this when I do IESG Evaluation on documents
with SHOULD), whenever a document uses SHOULD (or RECOMMENDED) it
needs to (one might say SHOULD) make it very clear what will happen
if you don't do this, so that implementors can have that necessary
understanding.  Perhaps the protocol will fail in some unusual
situations.  Perhaps it will break compatibility with older clients.
Perhaps it will still work, but will adversely affect performance.

But without an explanation, there's no way for implementors to meet
the terms in RFC 2119:

   3. SHOULD   This word, or the adjective RECOMMENDED, mean that
   there may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and
   carefully weighed before choosing a different course.

If something is simply a suggested value or response, the text should
say it that way.  If it's a suggestion that really is a best-practice
recommendation that comes from a lot of experience with the protocol,
the text should say that, without the 2119 key words.

For the first item, in Section 3.2, for example, you say:

 this should be It is RECOMMENDED that multiple endpoints not have the same
 identity.  if two endpoints have the same identity, then they will be 
 indistinguishable.
 this will not break RTMFP, but might confuse an application.  that being 
 said, there
 could potentially be reasons to have different endpoints with 
 indistinguishable identities
 and that potential should not be normatively prohibited.

That might well be a valid SHOULD.  Don't change it to RECOMMENDED
(or do, if you like), but put in the explanation that you have here.
It would be especially helpful if you can also include an example of a
reason, and/or say something about the consequences of the confusion
it will cause.

For the cases of 3.5.1.1.1 and 3.6.2.3.2, it seems that you don't want
2119 key words there at all: these look like recommendations (not in
the 2119 sense) that are based on what's been deployed already, and it
would simply be good to make that clear: implementation experience
suggests [x].

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

Re: [Gen-art] Gen-ART LC Review of draft-thornburgh-adobe-rtmfp-07

[Barry Leiba]

 -- Why does this need to be published as an IETF stream RFC?  If I
 understand correctly, this documents an existing protocol as implemented by
 commercial products. I agree with Martin's comment that there is value in
 publishing this sort of thing, but I applaud the Adobe and the author for
 publishing it so other implementations can interoperate with their
 products. But that could have done that in an independent stream document,
 or even in an Adobe published document. (Perhaps even in a prettier format
 ;-)  )  If we publish this as an IETF stream document, then I think it
 needs stronger clarification that it is not an IETF consensus doc than just
 its informational status.


 FWIW, the IESG has discussed this in the context of other documents, and
is looking at boilerplate that does not say that the document is a product
of the IETF, and makes it clear that the content is not a matter of IETF
consensus.  If that sort of boilerplate was used, do you think that would
be sufficient?

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

Re: [Gen-art] Gen-ART LC review of draft-ietf-appsawg-webfinger-11.txt

[Barry Leiba]

 Please see attached review.

I'll counter-complain (see below) that you're the only GenART reviewer
who sends reviews as attachments, and I find it a PitA.

 The draft was updated during Last Call, which I thought was not normal
 practice.  This review is of the updated draft, not the one that was Last
 Called.

I asked the authors to post it, so reviewers would be seeing the
latest version.  Now that we have the datatracker, this really should
not be a problem, and as a reviewer I appreciate not reviewing a
version with issues that others have already caught.

 There is no explicit discussion of privacy in the draft, which seems to
 me to carry evident privacy risks. For example, imagine an ISP that
 kindly decides to support webfinger for all customers by default,
 and preloads personally identifiable information without consent.

There's quite a bit of discussion in the Security Considerations of
personal information, revealing a user's current context, and so on.

 There is some relevant text in the Security Considerations:

Indeed.

 However, the weakness there is the words or implicitly. IANAL, but it
 seems highly likely that would be illegal in the European Union, at least.

And we are not lawyers either, and deployers in the EU will need to be
well aware of EU laws.  We shouldn't be telling them about those here.

 Has the draft been validated against the guidelines in
 draft-iab-privacy-considerations?

That'd be the document that's not even in the RFC Editor queue yet?

I don't know whether the authors have read that document; perhaps they
can say.  I did ask the authors to alert Alissa to this document, and
to explicitly ask her to review it.

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

Re: [Gen-art] Gen-ART (telechat) review of draft-ietf-geopriv-dhcp-lbyr-uri-option-18

[Barry Leiba]

 In Section 1: the first reference to URI needs a Normative reference. The
 whole document is about passing URIs and they are not defined anywhere.

 which RFC would you like me to reference?

RFC 3986 is the canonical reference for URIs.

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

Re: [Gen-art] Mail regarding draft-ietf-sidr-usecases

[Barry Leiba]

Hi, Sriram.

 As for all other comments from Stephen, Barry, Russ H., and Gen ART,
 they are all incorporated. Please let me know if you notice I missed
anything.

My two very minor comments are addressed fine.  Thanks for considering them.

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

Re: [Gen-art] Gen-ART Telechat review of draft-ietf-appsawg-json-pointer-08.txt

[Barry Leiba]

Murray is exactly right.  And, for what it's worth, the App Area has
discussed moving 4627 to Standards Track.

The experimental shepherd writeup template is here:
http://trac.tools.ietf.org/group/iesg/trac/wiki/DraftShepherdWriteupWgAlternate
...and I encourage shepherds to talk with your ADs about trying it out.

On the other item, the point is that the - is syntactically correct and
has the semantics specified in the first excerpt.  But, as the second
excerpt says, it references a non-existant array element, and so creates an
error from the point of view of the JSON Pointer.

It is, therefore, up to the use of the Pointer to say what this means.
 Some future uses might proceed to handle it as an error condition.  JSON
Patch defines it as a valid situation for the add operation, but an error
for all other operations.

Barry

On Tuesday, January 8, 2013, Murray S. Kucherawy wrote:

 HI Suresh,

 RFC4627 is already in the downref registry.  See
 http://trac.tools.ietf.org/group/iesg/trac/wiki/DownrefRegistry.

 The template used is a simplified one being tested by request of the IESG.

 I'll let the editors comment on the first question.

 -MSK


 On Mon, Jan 7, 2013 at 9:51 PM, Suresh Krishnan 
 suresh.krish...@ericsson.com javascript:_e({}, 'cvml',
 'suresh.krish...@ericsson.com'); wrote:

 I have been selected as the General Area Review Team (Gen-ART)
 reviewer for this draft (for background on Gen-ART, please see
 http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

 Please wait for direction from your document shepherd
 or AD before posting a new version of the draft.

 Document: draft-ietfdraft-ietf-appsawg-json-pointer-08.txt
 Reviewer: Suresh Krishnan
 Review Date: 2013/01/07
 IESG Telechat date: 2013/01/10

 Summary: This document is almost ready for publication as a Proposed
 Standard. I do have a minor comment that you may wish to address and a
 procedural point for the GEN AD to consider.

 Minor
 =

 * Section 4

 The following two pieces of text seem contradictory to me. It is
 possible that I am just misunderstanding something. If this is the case,
 please let me know.

 If the currently referenced value is a JSON array, the reference token
 MUST contain either:
 ...
 *  exactly the single character -, making the new referenced value
 the (non-existant) member after the last array element.

 Which seems to indicate that the character - is valid for use and this
 is followed by the following text at the end of the section

   Note that the use of the - character to index an array will always
result in such an error; applications of JSON Pointer thus need to
specify how it is to be handled, if it is to be useful.

 which seems to indicate that this is an error condition. Can you please
 clarify?

 Procedural
 ==

 * There is a downref to RFC4627 that has not been called out. I looked
 up the shepherd writeup at


 http://datatracker.ietf.org/wg/appsawg/management/shepherds/draft-ietf-appsawg-json-pointer/writeup/

 and it curiously seems to be incomplete. Has there been an update to the
 shepherd writeup since Feb 2012. The last one I know of is at

 http://www.ietf.org/iesg/template/doc-writeup.html

 Thanks
 Suresh





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

Re: [Gen-art] Gen-ART Telechat review of draft-ietf-appsawg-json-pointer-08.txt

[Barry Leiba]

Thinking further:

 Which seems to indicate that the character - is valid for use and this
 is followed by the following text at the end of the section

   Note that the use of the - character to index an array will always
result in such an error; applications of JSON Pointer thus need to
specify how it is to be handled, if it is to be useful.

 which seems to indicate that this is an error condition. Can you please
 clarify?

 the point is that the - is syntactically correct and
 has the semantics specified in the first excerpt.  But, as the second
 excerpt says, it references a non-existant array element, and so creates an
 error from the point of view of the JSON Pointer.

 It is, therefore, up to the use of the Pointer to say what this means.  Some
 future uses might proceed to handle it as an error condition.  JSON Patch
 defines it as a valid situation for the add operation, but an error for
 all other operations.

To be fair, I tripped over the same issue when I did my AD review,
then figured it out and didn't mention it in my review comments.  I do
think it could be clearer.

Perhaps something like this would make more sense (and also fixes the
implementations... it problem)?:

OLD
   Implementations will evaluate each reference token against the
   document's contents, and terminate evaluation with an error condition
   if it fails to resolve a concrete value for any of the JSON pointer's
   reference tokens.  For example, if an array is referenced with a non-
   numeric token, it will fail.  See Section 7 for details.

   Note that the use of the - character to index an array will always
   result in such an error; applications of JSON Pointer thus need to
   specify how it is to be handled, if it is to be useful.

NEW
   The implementations will evaluate each reference token against the
   document's contents, and will raise an error condition if it fails
   to resolve a concrete value for any of the JSON pointer's reference
   tokens.  For example, if an array is referenced with a non-numeric
   token, an error condition will be raised.  See Section 7 for details.

   Note that the use of the - character to index an array will always
   result in such an error condition because by definition it refers to a
   non-existent array element.  Applications of JSON Pointer thus
   need to specify how it is to be handled, if it is to be useful.

   Any error condition that does not have a specific action defined
   for it by the JSON Pointer application results in termination of
   evaluation.

END

Mark, what do you think?  Some wordsmithing, perhaps, but I think
something along this line will make the point clearer.

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

Re: [Gen-art] Gen-art review of draft-ietf-imapmove-command-02

[Barry Leiba]

Hi, Kathleen, and thanks for the review.  You left the document
shepherd and one of the editors off of the distribution list, so I'm
adding them in here.  Because of that, I'm not doing the trimming that
I'd normally do in my inline reply.

On Tue, Nov 20, 2012 at 3:01 PM, Moriarty, Kathleen
kathleen.moria...@emc.com wrote:
 I am the assigned Gen-ART reviewer for this draft. For background on
 Gen-ART, please see the FAQ at

 http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq.

 Please resolve these comments along with any other Last Call comments
 you may receive.

 Document:  draft-ietf-imapmove-command-02
 Reviewer: Kathleen Moriarty
 Review Date:
 IETF LC End Date:
 IESG Telechat date: (if known)

 Summary:  The document needs a little more work before it is ready and should
 address what happens when the series of commands fails to execute (logging,
 revert, etc.).  This should just result in either an incomplete copy (so 
 maybe a
 garbled message or extra messages being left behind (expunge operations did
 not occur).  This document does not cover that case and does not point to 
 another
 standard that covers that question.

This appears to be a repetition of the minor issues below, so I'm
responding to it there.

 Minor issues:  The security consideration section and the main body of the
 document do not explain what happens when the series of commands fails to
 execute or any associated risks.  It should not result in mail being deleted, 
 but
 rather being left in too many places or possible errors if the copy operation 
 did
 not complete (unless that is handled and just needs a refernce)?

What series of commands are you referring to?  The point here is
that there's *one* command, MOVE (or UID MOVE), which makes atomic a
function that is otherwise done with three separate commands (that
cause the problems you're noting, which is why we're creating a single
command to do it).  Is that really not explained sufficiently?  I
should think that the Introduction makes this clear.

As to what state the single MOVE command leaves things in, this
paragraph from Section 3 answers the questions you appear to have:

   Each message SHOULD either be moved or unaffected.  The server MUST
   NOT leave a message in neither mailbox, and SHOULD NOT leave a
   message in both mailboxes afterwards, even if the server returns a
   tagged NO response.  Note that these restrictions only apply to
   individual messages and not to the command as a whole, which can fail
   partway through.

See below for more discussion of that.

 Nits/editorial comments:
 Section 3.3 third paragraph:  NOT and neither form a double negative, the 
 phrase should use either instead of neither:
 The server MUST NOT leave a message in either mailbox

Absolutely not!  The double negative is quite necessary and
intentional.  One possible outcome if the MOVE of a single message
should fail internally would be that the message would be in *neither*
mailbox... perhaps the server removed it from the source mailbox
before putting it into the target, and there was some internal error,
server crash, or power failure at that point.  This is saying that
such a thing MUST NOT happen.

 In the last sentence of this same paragraph, is there a reference to what 
 happens in the very last clause if the command fails?
Note that these restrictions only apply to
individual messages and not to the command as a whole, which can fail
partway through.

I don't understand what you're asking here either.  The MOVE command
can operate on a set of messages in one command.  The paragraph is
saying that it has to operate successfully (that is, as described in
the earlier part of the paragraph) on each message, but that the
command can fail in the middle, having moved some of the messages but
not others.  It doesn't have to roll back successful moves if it can't
finish the rest.  Maybe this would be clearer to you?:

   These restrictions apply to each message in the set to be moved.
   If the command fails partway through, some messages might be moved,
   while others will not have been.

 Section 3.3 paragraph 5, can you add more context or clean up the paragraph 
 to make it easier to follow:
 Note that the server may send EXPUNGEs for other messages as well, if
any happen to have been expunged at the same time; this is normal
IMAP operation.

No further context is needed for anyone familiar with IMAP.  The IMAP
protocol allows the server to send EXPUNGE responses for any message
at any time, and this is just a reminder of that.  It could be
removed, and it would change nothing.  But it would be a bad idea to
repeat what's explained at length in RFC 3501.

 Section 3.3, paragraph 6: remove duplicate is allowed:
 Change from:
 Note that moving a message to the currently selected mailbox (that
is, where the source and target mailboxes are the same) is allowed
when copying the message to the currently selected mailbox is
allowed.
 

Re: [Gen-art] Gen-art review of draft-ietf-imapmove-command-02

[Barry Leiba]

 What series of commands are you referring to?  The point here is
 that there's *one* command, MOVE (or UID MOVE), which makes atomic a
 function that is otherwise done with three separate commands (that
 cause the problems you're noting, which is why we're creating a single
 command to do it).  Is that really not explained sufficiently?  I
 should think that the Introduction makes this clear.

 As to what state the single MOVE command leaves things in, this
 paragraph from Section 3 answers the questions you appear to have:

Each message SHOULD either be moved or unaffected.  The server MUST
NOT leave a message in neither mailbox, and SHOULD NOT leave a
message in both mailboxes afterwards, even if the server returns a
tagged NO response.  Note that these restrictions only apply to
individual messages and not to the command as a whole, which can fail
partway through.

 [KMM]:  It was the last part of the last sentence that raised the confusion,
 which can fail part way through.  What happens if it fails partway through?
 If this is answered in another RFC, can there be a pointer added to the RFC
 and section?  Or do you clarify this to say that a failure partway through is
 not acceptable?  I was reading this last sentence as the MOVE command
 as a whole contained several operations and one of those operations could 
 fail.

Got it.  Then this is really overlapping with this discussion, moved
up from below:

 The MOVE command
 can operate on a set of messages in one command.  The paragraph is
 saying that it has to operate successfully (that is, as described in
 the earlier part of the paragraph) on each message, but that the
 command can fail in the middle, having moved some of the messages but
 not others.  It doesn't have to roll back successful moves if it can't
 finish the rest.  Maybe this would be clearer to you?:

These restrictions apply to each message in the set to be moved.
If the command fails partway through, some messages might be moved,
while others will not have been.

 [KMM]: Okay, now I am a bit more confused.  Can the set of operations fail?
 Earlier in your response, you say it can't fail.  Then here, it says one of 
 the
 operations can fail.  I am fine with either, I just want to make sure it is 
 clear
 to the reader.  Is there any logging required when it fails?  If this is 
 specified
 in another IMAP document, maybe a quick reference would be helpful?

I don't think we ever refer to operations, so I'm still not sure
what you're confused about, but I am sure that you're confused.  So
let's try to sort that out.

The MOVE command can move a set of messages.  If the client sends
MOVE 1:50 Banana, that's asking the server to move the first 50
messages from the currently selected mailbox into the mailbox called
Banana.  Let's suppose that the currently selected mailbox is called
Apple.

The paragraph in question, so we have the context here, says this:

   Each message SHOULD either be moved or unaffected.  The server MUST
   NOT leave a message in neither mailbox, and SHOULD NOT leave a
   message in both mailboxes afterwards, even if the server returns a
   tagged NO response.  Note that these restrictions only apply to
   individual messages and not to the command as a whole, which can fail
   partway through.

What that paragraph is *trying* to tell you is this:

The MOVE command has to leave each message in a reasonable state.
That means that for each message in the message set (1:50), either
the message should be moved, or the message should be unaffected
(sentence 1).  For each message in the message set, the server MUST
NOT make it disappear from both Apple and Banana, and SHOULD NOT leave
it in *both* Apple and Banana (sentence 2).  This stuff applies to
each message individually... it's allowable for the server to fail to
move all 50 messages, as long as the previous two sentences apply.

Do you (think you) understand *that*?

I'll propose a reformulation of that paragraph in a moment, but first...

 Section 3.3 third paragraph:  NOT and neither form a double negative, the
 phrase should use either instead of neither:
 The server MUST NOT leave a message in either mailbox

 Absolutely not!  The double negative is quite necessary and
 intentional.  One possible outcome if the MOVE of a single message
 should fail internally would be that the message would be in *neither*
 mailbox... perhaps the server removed it from the source mailbox
 before putting it into the target, and there was some internal error,
 server crash, or power failure at that point.  This is saying that
 such a thing MUST NOT happen.

 [KMM]:  I think the correct grammar is to say either instead of neither
 and it has the same meaning that you intended.  The message would
 not be in either mailbox.

I think you're wrong.  MUST NOT be in either mailbox would mean that
it's not in Apple and it's also not in Banana.  Which is what you say
in your last comment, but it's not 

Re: [Gen-art] Gen-ART LC review of draft-leiba-5322upd-from-group-06

[Barry Leiba]

On Wed, Oct 17, 2012 at 8:50 PM, Dave Crocker d...@dcrocker.net wrote:
 I see no way to explain the narrow EAI use case in this context
 without either dragging in a whole bunch of EAI that has no business
 being here or leaving various things dangling.

 ack. mumble.

 So I'll suggest a bit of an amalgam, including a cross reference of the type
 I prefer to avoid:

1. State that this removes a restriction that was never essential.

2. State that the timing of this removal is to accomodate EAI and for its
 use of the now-available features, see [RFC].


On Thu, Oct 18, 2012 at 6:28 AM, John Levine jo...@taugh.com wrote
(with a large part of this distribution list removed):
So, is it better to put in a sentence about representing non-ASCII
text in the group name without including a replyable address?

 The main motivation is to provide a syntax for a non-replyable address
 in From: and Sender: headers for cases where that is appropriate.  See
 the EAI downgrade documents for a concrete example.

 A secondary motivation is to remove an arcane restriction that has not
 turned out to be useful in practice.

Dave and John (Levine) are both suggesting an informative reference
from this document to some piece of the EAI documents (which I guess
should be one or both of draft-ietf-eai-5738bis, Section 7, and
draft-ietf-eai-popimap-downgrade, Section 3.2.1).

Ned and John (Klensin), can you live with that (I know it's not your
preference).  All: which (or both) should the reference be to?

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

Re: [Gen-art] Gen-ART LC review of draft-leiba-5322upd-from-group-06

[Barry Leiba]

 Channeling my inner Maslow, I see the present text as best, an additional
 sentence or two as next best, a sentence and a cite to the downgrade doc
 next in line, and including actual EAI examples in this doc as the worst
 choice.

 The problem I have with the current text is that it says 'what' motivated
 the change, but not how it is useful for the intended class of uses.  The
 reader is left entirely to guess.

So, is it better to put in a sentence about representing non-ASCII
text in the group name without including a replyable address?

Or is it better to remove the notation about the EAI use case, and
just say that it's stupid to have the restriction, so we're removing
it?

I'm ambivalent.

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

Re: [Gen-art] Gen-ART LC Review of draft-ietf-eai-simpledowngrade-07

[Barry Leiba]

 -- Abstract should mention that this updates 3501

 Really? A detail of this document updates a minor detail of that document,
 that's hardly what I would expect to see in a single-paragraph summary.

 I know someone who likes to repeat the Subject in the first line of the
 email body text. Just in case I didn't see it the first time, I suppose.

There's no need to be flippant; this is called out by the idnits
program, and Ben is highlighting it.  It's not a big deal, but there
are reasons for it:

1. The updates (and obsoletes) information is not in the text of
the published RFC, but is part of the RFC's metadata.  Not everyone
who will look at the RFC will see the metadata.  Some will see only
Title and Abstract.  And so on.  It's not just frivolity to put
something in the Abstract.

2. We also like to have an *explanation* in the Introduction, saying
why a document updates another.  For that part, it's not just This
document updates RFC 3501, but This document updates RFC 3501
because it adds [this] and changes [that].

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

Re: [Gen-art] Gen-ART LC review of draft-ietf-sieve-imap-sieve-06

[Barry Leiba]

(Removed mail IETF list.)

 Summary: This draft is ready for publication as a standard track RFC.
...
 Nits/editorial comments:
 1.   At the end of section 3.7 and 3.8 “acton” “should be “action”

Ack; thanks.  Fixed in my local copy for the next update.

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

Re: [Gen-art] [marf] Gen-ART review: draft-ietf-marf-as-13

[Barry Leiba]

Just one comment here; leaving the rest for Murray:

Martin:
 Reading through, this doesn't smell very much like an applicability
 statement at all.  It has the distinct odor of a profile, or a set of
 implementation/deployment/operational guidelines.  That might just be
 me.

Murray:
 It is an Applicability Statement in the sense of Section 3.2 of RFC 2026.

Indeed, and the problem is that we've used stand-along Applicability
Statements so infrequently in recent years that we don't seem to know
what they are any more.  Worse, we've often started to call them
profiles.

I think an Applicability Statement is a normative document that does
not in itself define a protocol, but specifies how to *apply* one or
more profiles to solve a particular (set of) problem(s) or to perform
a particular (set of) function(s).  It might well be that we should
start calling many of the profiles that we do Applicability
Statements instead.

The advantage here is that the AS is a standards-track document, and
will progress along the standards track just as a Technical
Specification would.  Making it Information loses that aspect.

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

Re: [Gen-art] Gen-ART review of draft-ietf-marf-spf-reporting-10

[Barry Leiba]

 I am the assigned Gen-ART reviewer for this draft. For background on
 Gen-ART, please see the FAQ at
 http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq.

 Please resolve these comments along with any other Last Call comments
 you may receive.

 Document: draft-ietf-marf-spf-reporting-10

Thanks very much for the review, Vijay... but this document has been
through last call, the IESG, the telechat, and AD follow-up, and the
approval announcement was sent yesterday.

I'm glad you didn't find anything seriously wrong with it!

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

Re: [Gen-art] [sieve] Gen-ART Last Call Review of draft-ietf-sieve-include-13

[Barry Leiba]

 -- section 3.1, paragraph 4: Implementations MUST NOT generate errors for
 recursive inclusions at upload time, as this would force an upload ordering
 requirement upon script authors / generators.  However, if an active script
 is replaced with a faulty script and would remain the active script, an
 error MUST be generated and the upload MUST fail.

 These two statements seem contradictory on a quick reading.  In
 particular, how can the latter assertion avoid an upload ordering
 requirement? Or do you mean faulty in some way other than being recursive?

 If you're replacing an active script, it has to be correct all the time, and
 uploads are atomic only on a per-script basis. There's a risk that if you're
 uploading a set of scripts that include one another, at some intermediate
 stage while some scripts are uploaded but not others, they are in an invalid
 state. The managesieve spec says that scripts must be validated at upload
 time. The language above is trying to say that you can upload all of the
 scripts that may include one another in any order without generating errors
 immediately, however, if you're replacing an active script or a script
 included by the active script, then you DO have to upload a correct script
 right from the get-go.

 Is this just a question of whether the script(s) are replacing active
 scripts? That is, the license to create a transient invalid state is
 suspended if if you are replacing an active script? If so, how would one go
 about updating a set of linked scripts when one or more of them replace
 active scripts? Should one somehow deactivate the old ones, load all the
 scripts, then activate them?

 Having written this out, I don't recall how an implementation would
 handle this. I haven't had luck tracking down maling list discussion
 on the topic. I'll have to chase up on this.

I don't think this is a real problem; the text just needs a little
tweaking.  Errors should still be generated at upload time for any
detectable script errors OTHER THAN recursion.  What this is meant to
deal with is a situation where, say, we have this:

main includes sub-a
   sub-a includes sub-b
  sub-b includes sub-c

...and we want to rewrite things and  change the structure thus:

main includes sub-a
main includes sub-c
   sub-c includes sub-b
 [sub-b no longer includes sub-c]

This would require that we update sub-b *before* we update sub-c, or
else we'd get an error at upload time.  The text is meant to block the
recursion error, so we can update the scripts in any order.  However,
if the script gets run in the middle of the updates and we hit a
recursion situation, we WILL get a runtime error.

That's all that text is meant to do.

That said, it would be wise for implementations to provide a way to do
an atomic update of a set of scripts, because, clearly, multiple
scrips in some indeterminate intermediate upload state could do very
weird (and perhaps bad) things, even if no errors are generated during
their execution.

I think this isn't a protocol requirement, but a
quality-of-implementation issue.  But I do think the document could
have a paragraph discussing this, and warning of the consequences.

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

Re: [Gen-art] Gen-ART LC review of draft-ietf-sieve-notify-sip-message-05.txt

[Barry Leiba]

Thanks for the review, Brian.

 I was briefly confused by Section 2.4. (Notify tag :importance)

 It only mentions three possible values of Priority but RFC 3261
 mentions four (the extra one is emergency) and states that
 additional values can be defined elsewhere. I think it should be
 noted that the :importance tag can only express a subset of the SIP
 Priority header semantics, and does not provide a separate category
 for when life, limb, or property are in imminent danger [RFC3261].

Yes, that's a good point.

New text:
  The :importance tag is intended to convey the importance of the
  SIP MESSAGE notification, not the importance of the email message
  that generated the notification.
  The value of the :importance tag MAY, therefore, be
transformed into SIP
  Priority header field (in addition to or instead of
including it in the
  body of the message).
  Note that because the Sieve :importance tag only has three values,
  not all SIP Priority values can be represented in the
transformation.
  If this transformation is done, the value of the Priority
header field MUST be
  urgent if the value of the :importance tag is 1,
  normal if the value of the :importance tag is 2,
  and non-urgent if the value of the :importance tag is 3.
  There is no mapping to the SIP value emergency, nor to any
additional values
  that might be defined.

Does that work?

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

Re: [Gen-art] Gen-ART telechat review of draft-ietf-marf-not-spam-feedback-01.txt

[Barry Leiba]

 (Raised in LC review, no reply but it was only a week ago.)

Yes, sorry.  I got the review and am acting on it, but I was just
waiting to roll in all the comments for a revision.

In most cases, not-spam reports will probably not be taken on their
own, but will be considered along with other information, analysis of
the message, etc.

 Did you consider using a normative SHOULD NOT ... SHOULD instead
 of will probably not ... will?

We -- the editors and the working group -- did, and we thought it best
to put this in as narrative, rather than as anything normative.  The
WG thinks it's a difficult line to straddle, between giving advice on
how to handle this stuff and trying to tell operators what to do.

 Similarly, in the Security Considerations, Operators need to be careful
 seems very mild to me. Generating hundreds of not-spam reports seems
 like a very plausible gambit for a spamming botnet. (A bot receives spam
 from one of its own swarm, and generates a completely valid not-spam
 report to be sent to the victim's own provider. Repeat until done.)
 This would essentially nullify the value of any not-spam report,
 unless operators deploy heuristics to detect it.

Yes, and similarly here, with the balance.  In fact, operators are
well aware of what they have to do for these cases, and new ones
become aware quickly.  Still, each operator has its own way of dealing
with it.  The Messaging Anti-Abuse Working Group (MAAWG) has put out
their recommendations for how to use complaint feedback loops, and
some of what's in there will apply.  They're working on re-publishing
it in the IETF stream (
http://tools.ietf.org/html/draft-jdfalk-maawg-cfblbcp-01 ), and the
MARF WG is working on an Applicability Statement that cites the MAAWG
document and adds other recommendations (
https://tools.ietf.org/html/draft-ietf-marf-as is an early version).
We think that's the right place for more detailed, and more
normative-looking advice.

Probably the right thing to do is to put an informative reference into
this document to those other two (or just to the MARF AS), and I will
do that in the revision.

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

Re: [Gen-art] Gen-ART LC Review of draft-eggert-successful-bar-bof-06

[Barry Leiba]

 -- Section 6 suggests side meetings should be (somehow informally) covered
 by NOTE WELL. I think this is a very dangerous suggestion. The rest of the
 document suggests that a side meeting has no official standing. That seems to
 me to mean it's no different than a group of people who coincidentally 
 participate
 in the IETF having a dinner or bar meeting on any subject at any time. Or a 
 hallway
 conversation, for that matter. By the logic of this section, I can't really 
 figure out how
 informal a meeting would need to be before it no longer fell under NOTE 
 WELL.

This is truly a tricky point.  Often, organizers of these bar BoFs
make great effort to get an AD involved and attending, make it clear
that they're having this because their BoF proposal got in too late or
was denied, and/or talk about a proposed WG charter.  These side
meetings are often advertised during open area meetings and other
working-group sessions, and everyone is encouraged to attend.

In the first case, Note Well explicitly covers this (The IESG, or any
member thereof on behalf of the IESG); in the others, it does seem
like input to the IETF (any statement made within the context of an
IETF activity), if not unequivocally so, and it's certainly not
explicitly excluded (Statements made outside of an IETF session,
mailing list or other function, that are clearly not intended to be
input to an IETF activity, group or function, are not IETF
Contributions in the context of this notice.)

I'd like to hear from Jorge on this, but my spider sense says that if
a meeting occurs during an IETF week, is open to all, and clearly
relates to current or proposed work for the IETF, the people who go
have a reasonable expectation of Note Well terms.

 I think the best we can hope to do is suggest that side meeting organizers
 and participants be explicit with their expectations on IPR and 
 confidentiality,
 so there is less chance for down-stream surprises.

I think that's an excellent approach.  May I suggest some text?:

OLD
   Thus, the fact that a Contribution is made at one of the side
   meetings or other unofficial or semi-official events described in
   this document does not change or limit the applicability of the
   IETF's IPR rules.  If you have a question regarding the applicability
   of the IETF IPR rules in any specific context or to any specific
   activity, you should consult your attorney or make an inquiry to the
   IESG.

   Informally, the above makes it appropriate, in order to provide a
   pointer to the relevant policies, to announce the Note Well text
   [NOTEWELL] in all such meetings.

NEW
   Thus, a Contribution that is made at one of the side
   meetings or other unofficial or semi-official events described in
   this document could still be under the applicability of the
   IETF's IPR rules.  If you have a question regarding the applicability
   of the IETF IPR rules in any specific context or to any specific
   activity, you should consult your attorney or make an inquiry to the
   IESG.

   If a meeting occurs during an IETF week, is open to all, and clearly
   relates to current or proposed work for the IETF, those who attend
   will have a reasonable expectation that the IETF's rules apply.
   The organizers of these meetings are, therefore, strongly encouraged
   to make an explicit statement at the beginning of the meetings to
   announce whether or not they do apply (by using the Note Well text
   [NOTEWELL]).  If they do not apply, the announcement should
   specify what confidentiality and IPR terms are in effect.  In the absence
   of such a statement, attendees are encouraged to explicitly ask.

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

Re: [Gen-art] Gen-ART LC Review of draft-eggert-successful-bar-bof-06

[Barry Leiba]

 This is truly a tricky point.  Often, organizers of these bar BoFs
 make great effort to get an AD involved and attending, make it clear
 that they're having this because their BoF proposal got in too late or
 was denied, and/or talk about a proposed WG charter.  These side
 meetings are often advertised during open area meetings and other
 working-group sessions, and everyone is encouraged to attend.

 It seems like this draft discourages that sort of meeting in the first place, 
 doesn't it?

It does, but they will happen nonetheless.  The draft encourages
small, invited groups, but people *want* larger, open meetings, and
they'll do them.  I think it's important that we do what we can to get
people to make it clear what rules they're applying -- in that case,
and in all cases.

 NEW
   Thus, a Contribution that is made at one of the side
   meetings or other unofficial or semi-official events described in
   this document could still be under the applicability of the
   IETF's IPR rules.  If you have a question regarding the applicability
   of the IETF IPR rules in any specific context or to any specific
   activity, you should consult your attorney or make an inquiry to the
   IESG.

   If a meeting occurs during an IETF week, is open to all, and clearly
   relates to current or proposed work for the IETF, those who attend
   will have a reasonable expectation that the IETF's rules apply.
   The organizers of these meetings are, therefore, strongly encouraged
   to make an explicit statement at the beginning of the meetings to
   announce whether or not they do apply (by using the Note Well text
   [NOTEWELL]).  If they do not apply, the announcement should
   specify what confidentiality and IPR terms are in effect.  In the absence
   of such a statement, attendees are encouraged to explicitly ask.
...
 but I guess I'm looking for a way that someone could explicitly choose to 
 have a meeting
 where Note Well did not apply.

I agree, and I hope my suggested text says that.  If more needs to be
said, we (for some value of we that might mean Lars and Gonzalo)
can take another stab.

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

Re: [Gen-art] Gen-ART LC Review of draft-eggert-successful-bar-bof-06

[Barry Leiba]

 but I guess I'm looking for a way that someone could
 explicitly choose to have a meeting where Note Well did not
 apply.

 I think I disagree.  I don't know what a decision to Not apply
 the Note Well or, more specifically, to exempt oneself from the
 disclosure requirements of RFC 3979, 4879, and 5378, means and,
 especially wrt the disclosure requirements, if I do understand,
 I don't like it.

I suspect we're more in agreement than not.  Any group that wants to
hold a meeting that's during the IETF week seems free to do this under
whatever rules they like.  The IETF can apply its rules when it's
asked to get involved.  So if we want to say that, for example, any of
the following things can only happen if the meeting is covered by BCP
78, then we can certainly say that:
* IETF leadership is asked to get involved.
* IETF meeting rooms are used.
* The organizers want to announce the side meeting in an IETF session.

But, realistically, we can't demand that a group of organizers abide
by BCP 78 just because they hold a meeting during the IETF week and
don't put bouncers at the door barring entry to the uninvited.  If
they want to spread the word by mouth and get 100 people there on
Wednesday evening in the lobby lounge or in a private room at a local
restaurant, I don't see that we can tell them what to do.

But we can, and should, make them aware of what people's expectations
will be, urge them to apply BCP 78, urge them to announce whatever
rules they are applying, and urge those who might attend to hold them
to such disclosure (and perhaps vote with their feet if they don't
like the terms).  And that's what I think Ben and I are saying.

Of course, this is all from people who are not part of the IETF's
legal counsel, and said counsel certainly has the real say in this.  I
would like to see them weigh in publicly, to eliminate speculation
from us dilettantes.

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

Re: [Gen-art] Gen-ART Telechat review of draft-ietf-sieve-external-lists-09.txt

[Barry Leiba]

Thanks, Suresh, for the review.

 This following text is a bit handwavy. Is this by design? How can the sieve
 implementation identify the list as one that has an open subscriber list. Is
 the sieve engine expected to try one of these methods first and failover
 into another. Is there an expectation that all sieve implementations will
 actually be capable of invoking both these mechanisms?

 For some lists, the Sieve engine might directly retrieve the list and
 make its own comparison.  Other lists might not work that way -- they
 might provide a way to ask if a value is in the list, but not permit
 retrieval of the list itself.

Yes, it's vague by design.  The Sieve engine needs to be integrated
with the list handling -- this is saying that for some that's done
simply by having the Sieve engine retrieve the list and search it, but
for other lists it's done through some sort of API by which it
searches the list.  In any case, the Sieve engine needs to know how to
access each list that it supports... and that access is out of scope
here.

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

Re: [Gen-art] Gen-ART review of draft-ietf-morg-multimailbox-search-07

[Barry Leiba]

Thanks for the review, Vijay.

 - Section 5: ... in an expensive search of tens of thousands of
   mailboxes. --- Is this true or a hyperbole for effect?  Do people
   have tens of thousands of folders in an IMAP account (I believe
   the term mailbox equates to a folder).  I guess modern operating
   system allow millions of inodes (or their equivalent) on a
   filesystem, so technically you may be correct, of course.  I
   was just curious if operationally this is the case.

It's not hyperbole.  There have been IMAP servers that exposed tens of
thousands of Usenet newsgroups as shared IMAP mailboxes.  I think it's
unlikely (though possible) that any personal namespaces have tens of
thousands of private mailboxes, but it's easily possible for a
subtree search to hit that many in a situation such as this.

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

Re: [Gen-art] Gen-ART Telechat review of draft-ietf-sieve-vacation-seconds-02.txt

[Barry Leiba]

 The :seconds maximum only applies if :second is specified. Similarly for
 :days. (:seconds and :days parameters are mutually exclusive). So, IMHO,
 there is no interaction between maximums.

Indeed; they are entirely independent parameters, and that's clear in
the specification.

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

Re: [Gen-art] Gen-ART Last Call review of draft-ietf-sieve-notify-mailto-07

[Barry Leiba]

(Removed [EMAIL PROTECTED])

Thanks, Ben, for the review.

 URI headers with hname
received are considered unsafe, and will be ignored.

 Was that intended to be MUST be ignored?

Yes; I missed that one in a recent change from non-2119 language to 2119 
language.  I think I can fix that in AUTH48, unless there's a reason to put out 
another rev of the draft.

 IDNITS reports that draft-ietf-sieve-variables has been published as RFC 5229.
 Also, the [Notify] reference describes a very outdated version of that draft

Thanks; both of those will be fixed by the RFC Editor, so it won't matter.  But 
I'll run through the references during AUTH48, and make sure it all looks OK.

 Although one can get away with this when the noun in question is the
 document being referenced, as in ...notations are as in [Sieve] section 1.1
 ..., I find it visually disruptive to read The [Notify] extension to the
 [Sieve] mail filtering language My brain keeps stopping to wonder what is
 with all the square brackets--it is not immediately clear from context that 
 the
 brackets are there to denote references.

Yes, it's s style thing here.  Thanks for questioning it, but I think I'll 
leave 
it.  I find this sort of thing even more disruptive: The Notify extension 
[Notify] to the Sieve mail filtering language [Sieve]...  But, of course, it's 
all personal preference.

Barry

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