Subject: Gen-art LC review: draft-mcdonald-ipps-uri-scheme-16

From: Robert Sparks <[email-masked]>
Date: Fri, 21 Nov 2014 15:55:51 -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 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: Ira McDonald <[email-masked]>
Date: Mon, 24 Nov 2014 10:38:13 -0500

Hi Robert,

Small clarification to Mike Sweet's comment this morning - [RFC-IPPS] does
*not*
update [RFC3510].  As the [RFC-IPPS] abstract says, it's an alternative.
It does
indeed update [RFC2910] and [RFC2911].

The later versions of IPP protocol (2.0, 2.1, and 2.2) defined in IEEE-ISTO
PWG
specs normatively depend on over twenty other PWG specs (IPP and otherwise),
so republishing them as IETF RFCs is not feasible.

Thanks for catching the several reference errors and suggesting the
simplification
of the IPPS connection startup sequence.

I'm under the weather with flu, but will reply soon to your other comments.

Cheers,
- Ira

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 Mon, Nov 24, 2014 at 8:00 AM, Michael Sweet <[email-masked]> wrote:

> Robert,
>
> Thanks for your comments.  I have one response (inline below)...
>
> > On Nov 21, 2014, at 4:55 PM, Robert Sparks <[email-masked]> wrote:
> > ...
> parallel documents coordinating this. Is there such a parallel PWG doc this
> time?
>
> No.
>
> Generally speaking, the PWG IPP WG doesn't develop parallel documents for
> publication by both the PWG (IEEE-ISTO) and IETF - there is no point.  PWG
> documents include IANA registration templates which go through the usual
> registration process, independent of any IETF RFC publication.
>
> However, since RFC 3510 is an IETF document that was produced by the (now
> defunct) IETF IPP WG, and since this document is updating RFC 3510 (and
> inherits most of the text of RFC 3510), we (the PWG IPP WG) decided it
> should be submitted for publication by (and under the IP rules of) the IETF
> rather than publishing it as a PWG standard.  And Barry has graciously
> agreed to shepard the document...
>
>
> 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?
> >
> _________________________________________________________
> Michael Sweet, Senior Printing System Engineer, PWG Chair
>
>

---

From: Michael Sweet <[email-masked]>
Date: Mon, 24 Nov 2014 08:00:50 -0500

Robert,

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

No.

Generally speaking, the PWG IPP WG doesn't develop parallel documents for publication by both the PWG (IEEE-ISTO) and IETF - there is no point.  PWG documents include IANA registration templates which go through the usual registration process, independent of any IETF RFC publication.

However, since RFC 3510 is an IETF document that was produced by the (now defunct) IETF IPP WG, and since this document is updating RFC 3510 (and inherits most of the text of RFC 3510), we (the PWG IPP WG) decided it should be submitted for publication by (and under the IP rules of) the IETF rather than publishing it as a PWG standard.  And Barry has graciously agreed to shepard the document...

> 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?
> 
> 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.
> This reference is oddly constructed - please check early with the RFC Editor on whether they
> This line is wrong, and is causing idnits to complain once where it shouldn't.

---

From: Ira McDonald <[email-masked]>
Date: Tue, 25 Nov 2014 16:27:05 -0500

Hi Robert,

Some replies and questions inline in BLUE.

Barry - there are several places below in Robert's and my comments
where we need your guidance, I think.

I'll try to turn out a new draft ASAP, but would appreciate Barry's and
Robert's guidance before posting it.

Cheers,
- Ira

On Fri, Nov 21, 2014 at 4:55 PM, Robert Sparks <[email-masked]> wrote:

> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>
> 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?
>

<ira> (Slight clarification of Mike Sweet's earlier reply)
No.

However, since RFC 3510 is an IETF document that was produced by the (now
defunct) IETF IPP WG, and since this document is a parallel alternative to
RFC 3510 (and inherits most of the text of RFC 3510), we (the PWG IPP WG)
decided it should be submitted for publication by (and under the IP rules
of) the IETF rather than publishing it as a PWG standard.  And Barry has
graciously agreed to shepard the document...
</ira>

> organization's documents in the RFC series before...)

<ira> (Expanding my earlier reply)
The later versions of the IPP protocol (2.0, 2.1, and 2.2) defined in
IEEE-ISTO PWG
5100.12 normatively depend on over twenty other PWG specs (IPP and
otherwise),
so republishing them as IETF RFCs is not feasible.
</ira>

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

<ira>
We need some AD guidance from Barry here.  We could collapse steps 3-5 to a
pointer to HTTPS, if that's preferable.

We don't want anyone to "get creative" in checking a certificate, so
guidance in
how to say that best would be appreciated.
</ira>

> ID nits complains about all of these, and should make them easy to find

<ira>
I just ran ID Nits in the verbose mode and saved the output.

Unfortunately, the I-D submission checks didn't show any of these errors or
warnings.
We certainly need the extra boilerplate for the pre-RFC5378 work.  Several
of the
original authors of RFC 2910 and RFC 2911 are dead or unreachable AFAIK.

These ID Nits may take a little while to fix...
</ira>

> <ira>
That's a typo - should have been [RFC2817].
</ira>

> <ira>
We'll remove this composite reference - it's only ever used (incorrectly)
in the acronyms appendix.
</ira>

> <ira>
Yes - it's a cut-and-paste typo.
</ira>