attachment-0001
<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><br></div>Yeah, RFC 2845 pre-dates DNSSEC, and you can enable dns update (BIND 9) with 2845 mechanisms (TSIG), but it still requires administrative support (configuration), so it doesn't address my earlier point about administrative/site support.<div><br></div><div>2136 with 2845 would be easier to implement in clients than that described in my previous email, but there is a key management issue with 2845, including the fact that it uses an HMAC based on a deprecated hash function (MD5).</div><div><br></div><div>I think anything that requires admin support (wide-area bonjour or hierarchical DNS service) should probably be a "SHOULD". I'm not sure sites that are moving to DNSSEC would enable an older form of security if they're going to the trouble of implementing DNSSEC.</div><div><br></div><div>As I mentioned before, we could add a section to our documents that talks about compliance and "site requirements", which would address anything "NOT" in the device.</div><div><br></div><div>Randy</div><div><br></div><div><br><div><div><div>On Apr 10, 2012, at 4:43 PM, Michael Sweet wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Randy,<div><br></div><div>See:</div><div><br></div><div><span class="Apple-tab-span" style="white-space:pre"> </span><a href="http://dns-sd.org/ServerSetup.html">http://dns-sd.org/ServerSetup.html</a></div><div><br></div><div><br></div><div><div><div>On Apr 10, 2012, at 2:30 PM, Randy Turner wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><br></div>Hi Guys,<div><br></div><div>In theory, RFC 2136 would allow a client to update any RRset in a zone in DNS -- however, no one implements just RFC 2136 by itself, since the security implications would be enormous.</div><div><br></div><div>RFC 2136 would require a vendor to allocate a fair amount of development resources for implementation and testing.</div><div><br></div><div>In addition, early recommendations strongly suggested any implementation of RFC 2136 to also include an implementation of RFC 2137, which would require a bit more development and testing time.</div><div><br></div><div>However, RFC 2137 has been obsoleted through the introduction of DNSSEC mechanisms (RFC 4033, 4034, and 4035), which require a bit more development. It would also require the site to move their DNS servers to use DNSSEC.</div><div><br></div><div>Even with these pre-conditions, I'm still trying to determine if DNS server policies would allow arbitrary RRset updates (other than A/AAAA RR types)</div><div><br></div><div>Of course, MDNS (DNS-SD, ZeroConf, etc.) only requires mechanisms on the client (as everyone probably knows), and many imaging devices already support this technology, so I don't see any problem (at least for now) with making a "MUST" for MDNS records that assist IPP everywhere.</div><div><br></div><div>For server-based DNS, I would recommend against making this a "MUST", because the implications on vendors and sites may be too high -- I recommend making this requirement a "SHOULD" or "MAY".</div><div><br></div><div>I'll follow up some suggested wording for section 4.2.2, taking into account the above information.</div><div><br></div><div>Randy</div><div><br></div><div><br></div><div><div><div>On Apr 9, 2012, at 1:00 PM, Randy Turner wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><br></div>Yes, I understand that DNS-SD allows "self-publication" and I'm fine with that.<div><br></div><div>I guess it's the DNS server case that still (I believe) requires administrative assistance.</div><div><br></div><div>R.</div><div><br></div><div><br><div><div>On Apr 9, 2012, at 11:44 AM, Ira McDonald wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">Hi Randy,<br><br>Printers already commonly publish themselves in SLP (if servers are<br>present) and LDAP/Active Directory automatically.<br><br>Adding the IPP Everywhere MDNS requirement for DNS-SD publish<br>of LOC and TXT records is a matter of parity in discovery protocols.<br>
<br>Cheers,<br>- Ira<br><br clear="all">Ira McDonald (Musician / Software Architect)<br>Chair - Linux Foundation Open Printing WG<br>Secretary - IEEE-ISTO Printer Working Group<br>Co-Chair - IEEE-ISTO PWG IPP WG<br>Co-Chair - TCG Trusted Mobility Solutions WG<br>
Chair - TCG Embedded Systems Hardcopy SG<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<div style="display:inline"></div><div style="display:inline"></div><div style="display:inline"></div><div>
</div><div></div><div></div><div></div><br>
<br><br><div class="gmail_quote">On Mon, Apr 9, 2012 at 2:05 PM, Randy Turner <span dir="ltr"><<a href="mailto:rturner@amalfisystems.com">rturner@amalfisystems.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Hi Mike,<br>
<br>
You're right about multicast DNS not requiring site administration, but dynamic DNS is only designed to update A/AAAA records in a zone. I'm not aware of anyone using dynamic DNS to update TXT, SRV, or other resource records. I haven't seen this done.<br>
<span class="HOEnZb"><font color="#888888"><br>
Randy<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
On Apr 9, 2012, at 10:59 AM, Michael Sweet wrote:<br>
<br>
> Randy,<br>
><br>
> Thanks for the text. Comments below.<br>
><br>
> On Apr 9, 2012, at 10:24 AM, Randy Turner wrote:<br>
>><br>
>> Hi Guys,<br>
>><br>
>> Proposed mods for wd-ippeve10-20120201:<br>
>><br>
>> 4.2.2 Geo-Location (LOC)<br>
>><br>
>> Site administrators MUST (should this be a "SHOULD" ?) publish LOC records (RFC 1876) to provide the physical location of a printer.<br>
>><br>
>> 4.2.3 Service Information (TXT)<br>
>> Site administrators MUST publish ("SHOULD" ?)….<br>
>><br>
>><br>
>> This document is placing requirements on devices for future compliance with an IPP everywhere standard -- however, DNS requirements are NOT requirements placed on a device, but rather administrative requirements for the site DNS -- so I'm not sure that 4.2.2 and 4.2.3 belong in this document.<br>
><br>
> Multicast DNS (part of Bonjour, and a perennial draft awaiting love from the IETF DNS WG) is not managed by site administrators and is part of IPP Everywhere.<br>
><br>
> Also, printers *can* register their own DNS records with traditional DNS infrastructure using dynamic DNS updates (RFC 2136) and many already have support for this...<br>
><br>
> Anyways, I am happy to note that these are requirements for Multicast DNS and recommendations for traditional DNS.<br>
><br>
> ________________________________________________________________________<br>
> Michael Sweet, Senior Printing System Engineer, PWG Chair<br>
><br>
><br>
<br>
<br>
--<br>
This message has been scanned for viruses and<br>
dangerous content by MailScanner, and is<br>
believed to be clean.<br>
<br>
_______________________________________________<br>
ipp mailing list<br>
<a href="mailto:ipp@pwg.org">ipp@pwg.org</a><br>
<a href="https://www.pwg.org/mailman/listinfo/ipp" target="_blank">https://www.pwg.org/mailman/listinfo/ipp</a><br>
</div></div></blockquote></div><br>
</blockquote></div><br></div><br>--
<br>This message has been scanned for viruses and
<br>dangerous content by
<a href="http://www.mailscanner.info/"><b>MailScanner</b></a>, and is
<br>believed to be clean.
</div>
_______________________________________________<br>ipp mailing list<br><a href="mailto:ipp@pwg.org">ipp@pwg.org</a><br><a href="https://www.pwg.org/mailman/listinfo/ipp">https://www.pwg.org/mailman/listinfo/ipp</a><br></blockquote></div><br></div><br>--
<br>This message has been scanned for viruses and
<br>dangerous content by
<a href="http://www.mailscanner.info/"><b>MailScanner</b></a>, and is
<br>believed to be clean.
</div>
_______________________________________________<br>ipp mailing list<br><a href="mailto:ipp@pwg.org">ipp@pwg.org</a><br><a href="https://www.pwg.org/mailman/listinfo/ipp">https://www.pwg.org/mailman/listinfo/ipp</a><br></blockquote></div><br><div apple-content-edited="true">
<span class="Apple-style-span" style="font-family: Monaco; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><span class="Apple-style-span" style="border-collapse: separate; font-family: Monaco; font-size: medium; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>________________________________________________________________________</div><div>Michael Sweet, Senior Printing System Engineer, PWG Chair</div></div></span></div></span>
</div>
<br></div></div></blockquote></div><br></div></div><br />--
<br />This message has been scanned for viruses and
<br />dangerous content by
<a href="http://www.mailscanner.info/"><b>MailScanner</b></a>, and is
<br />believed to be clean.
</body></html>