attachment
<div dir="ltr"><div><div><div><div><div><div>Hi,<br><br></div>Large list of substantive issues/criticisms of RFC2910bis - I find it<br></div>particularly absurd that these comments say "this new protocol"<br></div>(in complete ignorance of Barry's writeup and the ubiquity of IPP/1.1).<br><br></div>Mike - we should mull these over and consider minimalist responses.<br><br></div>Cheers,<br></div>- Ira<br><br clear="all"><div><div><div><div><div><div><div><div><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">Ira McDonald (Musician / Software Architect)<br>Co-Chair - TCG Trusted Mobility Solutions WG<br>Chair - Linux Foundation Open Printing WG<br>Secretary - IEEE-ISTO Printer Working Group<br>Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG<br>IETF Designated Expert - IPP & Printer MIB<br>Blue Roof Music / High North Inc<br><a style="color:rgb(51,51,255)" href="http://sites.google.com/site/blueroofmusic" target="_blank">http://sites.google.com/site/blueroofmusic</a><br><a style="color:rgb(102,0,204)" href="http://sites.google.com/site/highnorthinc" target="_blank">http://sites.google.com/site/highnorthinc</a><br>mailto: <a href="mailto:blueroofmusic@gmail.com" target="_blank">blueroofmusic@gmail.com</a><br>Winter 579 Park Place Saline, MI 48176 734-944-0094<br>Summer PO Box 221 Grand Marais, MI 49839 906-494-2434<br><br><div style="display:inline"></div><div style="display:inline"></div><div style="display:inline"></div><div></div><div></div><div></div><div></div></div></div></div>
<br><div class="gmail_quote">---------- Forwarded message ----------<br>From: <b class="gmail_sendername">Mahesh Jethanandani</b> <span dir="ltr"><<a href="mailto:mjethanandani@gmail.com">mjethanandani@gmail.com</a>></span><br>Date: Wed, Jul 13, 2016 at 9:31 PM<br>Subject: OPS-DIR review of draft-sweet-rfc2910bis-07<br>To: <a href="mailto:draft-sweet-rfc2910bis.all@ietf.org">draft-sweet-rfc2910bis.all@ietf.org</a><br>Cc: <a href="mailto:ops-dir@ietf.org">ops-dir@ietf.org</a>, Benoit Claise <<a href="mailto:bclaise@cisco.com">bclaise@cisco.com</a>><br><br><br><div style="word-wrap:break-word"><div style="margin:0px;line-height:normal"><span>I have reviewed this document as part of the Operational directorate’s ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments.</span></div><div style="margin:0px;line-height:normal;min-height:14px"><span></span><br></div><div style="margin:0px;line-height:normal"><span>Document reviewed: draft-sweet-rfc2910bis-07</span></div><div style="margin:0px;line-height:normal;min-height:14px"><span></span><br></div><div style="margin:0px;line-height:normal"><span>Summary: </span></div>
<ul>
<li style="margin:0px;line-height:normal">The abstract of the document says “<span>This document is one of a set of documents, which together describe all aspects of a new Internet Printing Protocol (IPP). IPP is an application level protocol that can be used for distributed printing using Internet tools and technologies. This document defines the rules for encoding IPP operations and IPP attributes into the Internet MIME media type called "application/ipp". This document also defines the rules for transporting a message body whose Content-Type is "application/ipp" over HTTP.</span></li>
<li style="margin:0px;line-height:normal">This document is on a standards track.</li>
<li style="margin:0px;line-height:normal">It approved it will obsolete RFC 2910 and RFC 3382.</li>
</ul><div>Disclaimer: This document is a series of documents per the abstract. If operational and management considerations are covered in other documents, it needs to be called out and in that case most of the comments should be directed to that document.</div><div style="margin:0px;line-height:normal;min-height:14px"><br></div><div style="margin:0px;line-height:normal">Operational Considerations</div>
<ul>
<li style="margin:0px;line-height:normal">Operations. The document does talk about the minimum transport protocol needed for IPP. When describing the operation layer, it could talk about default values or range of values that any of the fields can take “out-of-the-box”. If the fields can take any value, it needs to state that. Operations like these need to monitored and for root cause analysis. Identifying information that is consistent such as what gets put in any field is helpful. </li>
</ul>
<ul>
<li style="margin:0px;line-height:normal">It is not apparent from the document if this new protocol places any requirements on other protocols and components in the network. These could be restrictions or creating dependencies on existing protocols. If it does, the requirements need to be called out.</li>
<li style="margin:0px;line-height:normal">The same is true for impact on operations of existing networks. If the impact is minimal, the document can just mention that. The impact should consider impact on servers performing auto-configuration for this protocol. Or impact on server or network if large print jobs are enqueued as a result of a spam.</li>
<li style="margin:0px;line-height:normal">How would an operator know that the protocol is operating correctly? Are there tests that network operators can run (other than enqueuing a print job) to test that the protocol is working properly. Are there particular metrics that an operator should watch out for?</li>
</ul><div style="margin:0px;line-height:normal;min-height:14px"><br></div><div style="margin:0px;line-height:normal">Management Considerations:</div>
<ul>
<li style="margin:0px;line-height:normal">From a management consideration point of view, the document needs to identify how the protocol is installed, configured and monitored once it is installed. That should include not only what needs to be managed but how. An identification of the managed identities that are involved, what the architecture of these entities are (client, server etc.), what some of the management operations are (static vs dynamic configuration) and whether these operations are performed locally or remotely.</li>
<li style="margin:0px;line-height:normal">Scale should be considered from a management perspective, specially for different scales. The document needs to consider the difference between a local management interface to manage a single device and how it would be different from a large network, remote management managed using a distributed management system. Auto configuration and default parameters might make more sense in the latter case.</li>
<li style="margin:0px;line-height:normal">Techniques for debugging protocol interactions in a network must be part of the document. This should include interoperability between devices from different vendors, and across models and releases from the same vendor.</li>
<li style="margin:0px;line-height:normal">Interoperability cannot be limited to protocol interaction. It has to extend to single syntax to do all the management on all the devices. This has to include both configuration and monitoring.</li>
<li style="margin:0px;line-height:normal">The document needs to describe some basic fault and health monitoring indications that needs to be instrumented. These should include alarms or events, e.g. out of paper if that is appropriate. </li>
<li style="margin:0px;line-height:normal">When propagating fault information, has the protocol considered mechanisms to throttle notifications to prevent congestion and duplication of events? If there is a hierarchy of faults, is each fault reported at every level or only at the lowest level?</li>
</ul><div style="margin:0px;line-height:normal;min-height:14px"><br></div><div style="margin:0px;line-height:normal">Accounting Considerations</div>
<ul>
<li style="margin:0px;line-height:normal">Is it appropriate to collect usage information related to this protocol? If so, what usage information would be appropriate to collect?</li>
</ul><div style="margin:0px;line-height:normal;min-height:14px"><br></div><div style="margin:0px;line-height:normal">A run of idnits reveals a few errors, warnings and comments:</div><div style="margin:0px;line-height:normal;min-height:14px"><br></div><div style="margin:0px;line-height:normal;font-family:Courier"><span> Checking nits according to <a href="http://www.ietf.org/id-info/checklist" target="_blank">http://www.ietf.org/id-info/checklist</a> :</span></div><div style="margin:0px;line-height:normal;font-family:Courier"><span> ----------------------------------------------------------------------------</span></div><div style="margin:0px;line-height:normal;font-family:Courier;min-height:14px"><span></span><br></div><div style="margin:0px;line-height:normal;font-family:Courier"><span> -- The draft header indicates that this document obsoletes RFC3382, but the</span></div><div style="margin:0px;line-height:normal;font-family:Courier"><span> abstract doesn't seem to mention this, which it should.</span></div><div style="margin:0px;line-height:normal;font-family:Courier;min-height:14px"><span></span><br></div><div style="margin:0px;line-height:normal;font-family:Courier"><span> -- The draft header indicates that this document obsoletes RFC2910, but the</span></div><div style="margin:0px;line-height:normal;font-family:Courier"><span> abstract doesn't seem to mention this, which it should.</span></div><div style="margin:0px;line-height:normal;font-family:Courier;min-height:14px"><span></span><br></div><div style="margin:0px;line-height:normal;font-family:Courier;min-height:14px"><span></span><br></div><div style="margin:0px;line-height:normal;font-family:Courier"><span> Miscellaneous warnings:</span></div><div style="margin:0px;line-height:normal;font-family:Courier"><span> ----------------------------------------------------------------------------</span></div><div style="margin:0px;line-height:normal;font-family:Courier;min-height:14px"><span></span><br></div><div style="margin:0px;line-height:normal;font-family:Courier"><span> -- The document date (June 13, 2016) is 30 days in the past. Is this</span></div><div style="margin:0px;line-height:normal;font-family:Courier"><span> intentional?</span></div><div style="margin:0px;line-height:normal;font-family:Courier;min-height:14px"><span></span><br></div><div style="margin:0px;line-height:normal;font-family:Courier;min-height:14px"><span></span><br></div><div style="margin:0px;line-height:normal;font-family:Courier"><span> Checking references for intended status: Proposed Standard</span></div><div style="margin:0px;line-height:normal;font-family:Courier"><span> ----------------------------------------------------------------------------</span></div><div style="margin:0px;line-height:normal;font-family:Courier;min-height:14px"><span></span><br></div><div style="margin:0px;line-height:normal;font-family:Courier"><span> (See RFCs 3967 and 4897 for information about using normative references</span></div><div style="margin:0px;line-height:normal;font-family:Courier"><span> to lower-maturity documents in RFCs)</span></div><div style="margin:0px;line-height:normal;font-family:Courier;min-height:14px"><span></span><br></div><div style="margin:0px;line-height:normal;font-family:Courier"><span> -- Looks like a reference, but probably isn't: '1' on line 1610</span></div><div style="margin:0px;line-height:normal;font-family:Courier"><span> '[1] <a href="http://www.pwg.org/" target="_blank">http://www.pwg.org/</a>...'</span></div><div style="margin:0px;line-height:normal;font-family:Courier;min-height:14px"><span></span><br></div><div style="margin:0px;line-height:normal;font-family:Courier"><span> == Missing Reference: 'RFC2910bis' is mentioned on line 1284, but not</span></div><div style="margin:0px;line-height:normal;font-family:Courier"><span> defined</span></div><div style="margin:0px;line-height:normal;font-family:Courier"><span> '(see [RFC2910bis]) or other transport protocol. Messages of type...'</span></div><div style="margin:0px;line-height:normal;font-family:Courier;min-height:14px"><span></span><br></div><div style="margin:0px;line-height:normal;font-family:Courier"><span> -- Possible downref: Non-RFC (?) normative reference: ref. 'ASCII'</span></div><div style="margin:0px;line-height:normal;font-family:Courier;min-height:14px"><span></span><br></div><div style="margin:0px;line-height:normal;font-family:Courier"><span> ** Downref: Normative reference to an Informational RFC: RFC 2818</span></div><div style="margin:0px;line-height:normal;font-family:Courier;min-height:14px"><span></span><br></div><div style="margin:0px;line-height:normal;font-family:Courier;min-height:14px"><span></span><br></div><div style="margin:0px;line-height:normal;font-family:Courier"><span> Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 5 comments (--).</span></div><div style="margin:0px;line-height:normal;min-height:14px"><br></div><div><br></div><div>
<div>Thanks</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>Mahesh Jethanandani</div><div><a href="mailto:mjethanandani@gmail.com" target="_blank">mjethanandani@gmail.com</a></div><div><br></div><br>
</font></span></div>
<br></div></div><br></div></div></div></div></div></div></div></div>