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

From: Robert Sparks <[email-masked]>
Date: Tue, 02 Dec 2014 10:31:00 -0600

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

---

From: Barry Leiba <[email-masked]>
Date: Tue, 2 Dec 2014 12:00:30 -0500

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

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

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.

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.

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

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

Barry

---

From: Robert Sparks <[email-masked]>
Date: Tue, 02 Dec 2014 11:13:11 -0600

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

> be removed by the RFC Editor.
Ok - thanks - I hadn't spotted that.

---

From: Barry Leiba <[email-masked]>
Date: Tue, 2 Dec 2014 12:20:20 -0500

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

I can do that, sure.

> 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

---

From: Michael Sweet <[email-masked]>
Date: Tue, 02 Dec 2014 14:01:54 -0500

> On Dec 2, 2014, at 12:20 PM, Barry Leiba <[email-masked]> wrote:
> 

And FWIW, the sections in question currently reference RFC 3510 along with the various TLS RFCs.  At some point in the next year we will be updating IPP/2.0 to full IEEE standard, at which point the references in those sections will be updated accordingly.

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

---

From: Pete Resnick <[email-masked]>
Date: Tue, 2 Dec 2014 22:51:13 -0600

> documents, that's their process, not ours, no?

This is to be an IETF document. If the PWG wants to say in one of their 
documents that PWG5100.12 is updated by this IETF document, that's their 
business. But *we* can't say in *our* document that we're updating their 
document. If you need a note, it could say:

       Note: IEEE-ISTO PWG has indicated that they intend to use this
       document as an update to their IPP Version 2.0 Second Edition
       [PWG5100.12], by extending section 4 'IPP Standards' and section
       10 'Security Considerations'.

But (c) should go.

pr

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478

---

From: Ira McDonald <[email-masked]>
Date: Tue, 2 Dec 2014 23:58:01 -0500

Hi Pete and Robert,

My mistake - agreed - (c) should go - and no need for the note about PWG
IPP/2.0.
(which will get updated anyway to reference the IETF IPPS spec next year).

Cheers,
- Ira (wearing PWG IPP co-chair and IPP/2.0 co-editor hats)

Ira McDonald (Musician / Software Architect)
Co-Chair - TCG Trusted Mobility Solutions WG
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music / High North Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthinc
mailto: [email-masked]
Winter  579 Park Place  Saline, MI  48176  734-944-0094
Summer  PO Box 221  Grand Marais, MI 49839  906-494-2434

On Tue, Dec 2, 2014 at 11:51 PM, Pete Resnick <[email-masked]>
wrote:

>>> same

---

From: Jari Arkko <[email-masked]>
Date: Thu, 4 Dec 2014 15:26:40 +0200

Many thanks of the review, Robert. 

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

Jari

---

From: Barry Leiba <[email-masked]>
Date: Thu, 4 Dec 2014 08:29:00 -0500

We'll get a revised draft.

Barry