Subject: [Gen-art] Gen-ART Review of draft-sweet-rfc2911bis-09

From: Russ Housley <[email-masked]>
Date: Tue, 26 Jul 2016 14:36:20 -0400

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

Document: draft-sweet-rfc2911bis-09
Reviewer: Russ Housley
Review Date: 2016-07-14
IETF LC End Date: 2016-07-29
IESG Telechat date: unknown

Summary: Almost Ready

The document is long, but it is well written.  I could not find the
time to read it in one sitting, so I hope I retained enough state from
one sitting to the next.  Apologies in advance if I lost too much state
between sittings.

I did not review the appendices.

Major Concerns:

It seems that [PWG5100.12] specifies IPP Version 2.0, 2.1, and 2.2.  Why
is this document specifying IPP Version 1.1?  I think the introduction
ought to contain an explanation of this situation.  Further, I expect
this will have some impact on the discussion of the REQUIRED
ipp-versions-supported attribute.

The two IANA references are broken.  They should point to iana.org.
The [IANA-CS] and [IANA-MT] should point to these URLs:
<http://www.iana.org/assignments/character-sets/character-sets.xhtml>
and <http://www.iana.org/assignments/media-types/media-types.xhtml>.

Minor Concerns:

Throughout the document, "Printer object" and "IPP object" and "Printer"
are used.  I think they mean the same thing.  If they are different,
please include a discussion in the Introduction.  If they are the same,
I think that using one throughout would be helpful.

How does the concepts of an impression (in Section 2.3.4) and a media
sheet (in Section 2.3.8) apply to a 3D printer?  Also, many of the
description and status attributes described in Section 5.4 do not seem
relevant to a 3D printer.

In Section 3.1, it says: "The following figures show ...".  However, it
is talking about Figure 2, which shows several configurations.  Either
label each configuration as a separate figure, or reword this text to
match the existing Figure 2.

In Section 4.1.3, it says: "Sections 4.1.7, 4.2.1.2, and C give ...".  I
found this confusing.  I think that Section C is really a reference to
Appendix C.

In section 4.1.7, it says:

   This value's syntax type is "out-of-band" and its encoding is defined
   by special rules for "out-of-band" values in the "Encoding and
   Transport" document [RFC2910bis].  Its value indicates no support for
   the attribute itself - see the beginning of Section 5.1.

Please clarify whether the referenced section is in [RFC2910bis] or this
document.

In Sections 4.1.9, 4.2.1.2, and 4.2.2. there are references to [RFC3196]
and [PWG5100.19], saying that these documents "present suggested steps".
Please reword this sentence to indicate whether these steps
MUST/SHOULD/MAY be followed.

In Section 5.2.11, there are references to [PWG5100.3] and [PWG5100.13].
Please reword this sentence to indicate whether these steps
MUST/SHOULD/MAY be followed.

Nits:

The URL for [1] and [3] are the same.  Get rid of [3].

In Section 1.1: s/The model described in this model document /
                 /The model described in this document /

In Section 1.1: s/some sort of filtered and context based searching /
                 /some sort of filtered context-based searching /

In Sections 4.1.6.4 and 5.3.11, there is an example URL.  It would be
better to use "example.com" or "example.net" in the URL.  Consider:

   (404) http://ftp.example.com/pub/ipp-model-v11-990510.pdf

In Section 5.3.7, the reference to "Figure 1" should be "Figure 3", and
the legend on the figure on that same page should be corrected.  The
figure is currently labelled with two numbers.

---

From: Michael Sweet <[email-masked]>
Date: Tue, 26 Jul 2016 17:54:06 -0400

Russ,

Thank you for reviewing this (admittedly long) document.  Responses to your questions and comments are inline below...

> On Jul 26, 2016, at 2:36 PM, Russ Housley <[email-masked]> wrote:
> ...
> Major Concerns:
> 

IPP/1.1 was defined in 1999/2000.  IPP/2.0 was originally defined in 2009 and has had several updates since then, but it shares the same message format and semantics - the main difference is in the required operations and attributes compared to IPP/1.1.  I'll add a note that IPP 2.0, 2.1, and 2.2 are defined separately.

> and <http://www.iana.org/assignments/media-types/media-types.xhtml>.

I will update these accordingly.

> I think that using one throughout would be helpful.

Generally speaking, "Printer" and "Job" are shorthand for "Printer object" and "Job object".  "IPP object" means any IPP object (Printer or Job in this document, there are others defined in other documents...)  I can look at making this clearer in the introduction to the model.

> relevant to a 3D printer.

That's because IPP/1.1 is exclusively for 2D printers...

(The PWG is defining an IPP/2.0 extension for 3D printers which includes new attributes and values specific to 3D printers.)

> match the existing Figure 2.

Will fix.

> found this confusing.  I think that Section C is really a reference to

Correct.

> Please clarify whether the referenced section is in [RFC2910bis] or this

Will fix.

> MUST/SHOULD/MAY be followed.

The implementor's guides are informative documents (and references), so I don't believe conformance terminology is appropriate here.

> MUST/SHOULD/MAY be followed.

I can make this a MAY.

> The URL for [1] and [3] are the same.  Get rid of [3].

That's an artifact of xml2rfc; I've replaced the eref's with a xref to an informative reference.

>                 /some sort of filtered context-based searching /

Will fix.

>   (404) http://ftp.example.com/pub/ipp-model-v11-990510.pdf

This is actually a real link to an (old) archived draft of the original RFC 2911, but I can update it to be a fake example.com URL...

> figure is currently labelled with two numbers.

This is probably a bug in the XML sources; will fix.

_________________________________________________________
Michael Sweet, Senior Printing System Engineer