Return-Path: X-Original-To: gen-art@ietfa.amsl.com Delivered-To: gen-art@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01DBA1A1BF8; Tue, 2 Dec 2014 08:31:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p1wFthy4nGRD; Tue, 2 Dec 2014 08:31:12 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 102AD1A1EF2; Tue, 2 Dec 2014 08:31:06 -0800 (PST) Received: from unnumerable.local ([173.64.248.98]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id sB2GV5qh016588 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 2 Dec 2014 10:31:05 -0600 (CST) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host [173.64.248.98] claimed to be unnumerable.local Message-ID: <547DE944.9000709@nostrum.com> Date: Tue, 02 Dec 2014 10:31:00 -0600 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: General Area Review Team , "ietf@ietf.org" , draft-mcdonald-ipps-uri-scheme.all@tools.ietf.org References: <546FB4E7.7060704@nostrum.com> In-Reply-To: <546FB4E7.7060704@nostrum.com> Content-Type: multipart/alternative; boundary="------------010909040209020806050007" Archived-At: http://mailarchive.ietf.org/arch/msg/gen-art/5ysoiPBY1V9ZLT35Paes87bqkbQ Subject: [Gen-art] Gen-art telechat review: draft-mcdonald-ipps-uri-scheme-17 X-BeenThere: gen-art@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "GEN-ART: General Area Review Team" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Dec 2014 16:31:16 -0000 This is a multi-part message in MIME format. --------------010909040209020806050007 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit 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 wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-mcdonald-ipps-uri-scheme-17 Reviewer: Robert Sparks Review Date: 2-Dec-2014 IETF LC End Date: past IESG Telechat date: 4-Dec-2014 Summary: Almost ready, but with nits that need to be addressed Jari/IESG: Please see my question about updating documents that are in other organization's change control below. Authors: 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. > == Missing Reference: 'MEDIAREG' is mentioned on line 829, but not defined > > == Missing Reference: 'RFC2818' is mentioned on line 862, but not defined > > == Missing Reference: 'RFC2616' is mentioned on line 955, but not defined > > ** Obsolete undefined reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, > RFC 7232, RFC 7233, RFC 7234, RFC 7235) > > == Missing Reference: 'RFC2246' is mentioned on line 1082, but not defined > > ** Obsolete undefined reference: RFC 2246 (Obsoleted by RFC 4346) > > == Missing Reference: 'RFC4346' is mentioned on line 1082, but not defined > > ** Obsolete undefined reference: RFC 4346 (Obsoleted by RFC 5246) > > -- Possible downref: Non-RFC (?) normative reference: ref. 'ASCII' > > -- Obsolete informational reference (is this intentional?): RFC 2566 > (Obsoleted by RFC 2911) On 11/21/14 3:55 PM, Robert Sparks 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-mcdonald-ipps-uri-scheme-16 > Reviewer: Robert Sparks > Review Date: 21-Nov-2014 > IETF LC End Date: 25-Nov-2014 > IESG Telechat date: 4-Dec-2014 > > Summary: Almost ready, but has nits that should be addressed before > publication as a Proposed Standard > > Nits/editorial comments: > > 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...) > > Second: The 6 step construction in section 3 is a little odd. Why > aren't steps 3-5 collapsed into one step that says "go do what https: > says to do"? Split this way, especially with the repeated guidance in > the security considerations section pointing somewhat loosely to 7320 > and 5246 for things that "can be used to address this threat" looks > like an opportunity for someone to get creative with how they check > the certificate supplied by the server against the name in the URI. If > you don't want anything but what happens in https to happen, I think > it needs to be more clearly stated. Otherwise, doesn't this go off > into RFC 6125 territory? > > Lastly (and much smaller nits): > > There are several callouts from the text that look like references > that are not represented in the references section. > ID nits complains about all of these, and should make them easy to > find and fix. > For example (from section 1.2): >> 2) Some existing IPP Client and IPP Printer implementations of HTTP >> Upgrade [RFC 2717] do not perform upgrade at the beginning of > This reference is oddly constructed - please check early with the RFC > Editor on whether they > will take this, or want something a little different. >> [HTTP1.1] HTTP/1.1. See [RFC7230], [RFC7231], [RFC7232], >> [RFC7233], [RFC7234], and [RFC7235]. > This line is wrong, and is causing idnits to complain once where it > shouldn't. > (The thing in the [] should be RFC7235, not 4): >> [RFC7234] Fielding, R., and J. Reschke, "Hypertext Transfer Protocol >> (HTTP/1.1): Authentication", RFC 7235, June 2014. > > > > > > > --------------010909040209020806050007 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit 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 wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-mcdonald-ipps-uri-scheme-17
Reviewer: Robert Sparks
Review Date: 2-Dec-2014
IETF LC End Date: past
IESG Telechat date: 4-Dec-2014

Summary: Almost ready, but with nits that need to be addressed

Jari/IESG: Please see my question about updating documents that are in other organization's change control below.

Authors:

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.

  == Missing Reference: 'MEDIAREG' is mentioned on line 829, but not defined

  == Missing Reference: 'RFC2818' is mentioned on line 862, but not defined

  == Missing Reference: 'RFC2616' is mentioned on line 955, but not defined

  ** Obsolete undefined reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231,
     RFC 7232, RFC 7233, RFC 7234, RFC 7235)

  == Missing Reference: 'RFC2246' is mentioned on line 1082, but not defined

  ** Obsolete undefined reference: RFC 2246 (Obsoleted by RFC 4346)

  == Missing Reference: 'RFC4346' is mentioned on line 1082, but not defined

  ** Obsolete undefined reference: RFC 4346 (Obsoleted by RFC 5246)

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

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




On 11/21/14 3:55 PM, Robert Sparks 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-mcdonald-ipps-uri-scheme-16
Reviewer: Robert Sparks
Review Date: 21-Nov-2014
IETF LC End Date: 25-Nov-2014
IESG Telechat date: 4-Dec-2014

Summary: Almost ready, but has nits that should be addressed before publication as a Proposed Standard

Nits/editorial comments:

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

Second: The 6 step construction in section 3 is a little odd. Why aren't steps 3-5 collapsed into one step that says "go do what https: says to do"? Split this way, especially with the repeated guidance in the security considerations section pointing somewhat loosely to 7320 and 5246 for things that "can be used to address this threat" looks like an opportunity for someone to get creative with how they check the certificate supplied by the server against the name in the URI. If you don't want anything but what happens in https to happen, I think it needs to be more clearly stated. Otherwise, doesn't this go off into RFC 6125 territory?

Lastly (and much smaller nits):

There are several callouts from the text that look like references that are not represented in the references section.
ID nits complains about all of these, and should make them easy to find and fix.
For example (from section 1.2):
  2) Some existing IPP Client and IPP Printer implementations of HTTP
      Upgrade [RFC 2717] do not perform upgrade at the beginning of
This reference is oddly constructed - please check early with the RFC Editor on whether they
will take this, or want something a little different.
[HTTP1.1]     HTTP/1.1.  See [RFC7230], [RFC7231], [RFC7232],
              [RFC7233], [RFC7234], and [RFC7235].
This line is wrong, and is causing idnits to complain once where it shouldn't.
(The thing in the [] should be RFC7235, not 4):
   [RFC7234]  Fielding, R., and J. Reschke, "Hypertext Transfer Protocol
              (HTTP/1.1):  Authentication", RFC 7235, June 2014.








--------------010909040209020806050007--