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 491AF1A06E9; Tue, 2 Dec 2014 09:13:26 -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 KYQ5vsGLS8mz; Tue, 2 Dec 2014 09:13:19 -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 C6AD21A1A73; Tue, 2 Dec 2014 09:13:19 -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 sB2HDGQO020890 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 2 Dec 2014 11:13:16 -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: <547DF327.6040803@nostrum.com> Date: Tue, 02 Dec 2014 11:13:11 -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: Barry Leiba References: <546FB4E7.7060704@nostrum.com> <547DE944.9000709@nostrum.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------000003020700070303030801" Archived-At: http://mailarchive.ietf.org/arch/msg/gen-art/UegPCmc38_BhDLddWUDX4gIPYKQ Cc: General Area Review Team , "ietf@ietf.org" , draft-mcdonald-ipps-uri-scheme.all@tools.ietf.org Subject: Re: [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 17:13:27 -0000 This is a multi-part message in MIME format. --------------000003020700070303030801 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit On 12/2/14 11:00 AM, Barry Leiba wrote: > 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? I mostly meant the writeup - I expect there will be IESG folks with the same questions I had. But see below. > > 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? The document says: 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. Maybe it would help to be specific about _how_ this document is updating that external document? > >> 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. Ok - thanks - I hadn't spotted that. > > 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 --------------000003020700070303030801 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
On 12/2/14 11:00 AM, Barry Leiba wrote:
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?
I mostly meant the writeup - I expect there will be IESG folks with the same questions I had.
But see below.

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?
The document says:
   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.

Maybe it would help to be specific about _how_ this document is updating
that external document?




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.
Ok - thanks - I hadn't spotted that.

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

--------------000003020700070303030801--