Subject: [IPP] proposed mods to IPP everywhere spec (per my action item)

From: Randy Turner <[email-masked]>
Date: Mon, 9 Apr 2012 10:24:45 -0700

Hi Guys,

Proposed mods for wd-ippeve10-20120201:

4.2.2 Geo-Location (LOC)

Site administrators MUST (should this be a "SHOULD" ?) publish LOC records (RFC 1876) to provide the physical location of a printer. 

4.2.3 Service Information (TXT)
Site administrators MUST publish ("SHOULD" ?)….

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.

There's nothing a printer vendor can do to be "compliant" with 4.2.2 and 4.2.3

We may want a separate section of our documents that place requirements on the "site" where devices are installed.

Comments?

Randy

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

_______________________________________________
ipp mailing list
[email-masked]
https://www.pwg.org/mailman/listinfo/ipp

---

From: Michael Sweet <[email-masked]>
Date: Mon, 09 Apr 2012 10:59:30 -0700

Randy,

Thanks for the text.  Comments below.

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

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.

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

Anyways, I am happy to note that these are requirements for Multicast DNS and recommendations for traditional DNS.

________________________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

---

From: Randy Turner <[email-masked]>
Date: Mon, 9 Apr 2012 11:05:03 -0700

Hi Mike,

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.

Randy

---

From: Ira McDonald <[email-masked]>
Date: Mon, 9 Apr 2012 14:44:13 -0400

Hi Randy,

Printers already commonly publish themselves in SLP (if servers are
present) and LDAP/Active Directory automatically.

Adding the IPP Everywhere MDNS requirement for DNS-SD publish
of LOC and TXT records is a matter of parity in discovery protocols.

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG IPP WG
Co-Chair - TCG Trusted Mobility Solutions WG
Chair - TCG Embedded Systems Hardcopy SG
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, Apr 9, 2012 at 2:05 PM, Randy Turner <[email-masked]>wrote:

>
> Hi Mike,
>
> 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.
>
> Randy
>
> >> Site administrators MUST (should this be a "SHOULD" ?) publish LOC
> records (RFC 1876) to provide the physical location of a printer.
> >>
> >> 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.
> >
> > 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.
> >
> > 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...
> >
> > Anyways, I am happy to note that these are requirements for Multicast
> DNS and recommendations for traditional DNS.
> >

---

From: Randy Turner <[email-masked]>
Date: Mon, 9 Apr 2012 13:00:59 -0700

Yes, I understand that DNS-SD allows "self-publication" and I'm fine with that.

I guess it's the DNS server case that still (I believe) requires administrative assistance.

R.

On Apr 9, 2012, at 11:44 AM, Ira McDonald wrote:

> On Mon, Apr 9, 2012 at 2:05 PM, Randy Turner <[email-masked]> wrote:
> 
> Hi Mike,
>

---

From: Randy Turner <[email-masked]>
Date: Tue, 10 Apr 2012 14:30:22 -0700

Hi Guys,

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.

RFC 2136 would require a vendor to allocate a fair amount of development resources for implementation and testing.

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.

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.

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)

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.

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

I'll follow up some suggested wording for section 4.2.2, taking into account the above information.

Randy

---

From: Michael Sweet <[email-masked]>
Date: Tue, 10 Apr 2012 16:43:09 -0700

Randy,

See:

	http://dns-sd.org/ServerSetup.html

---

From: Randy Turner <[email-masked]>
Date: Tue, 10 Apr 2012 18:57:37 -0700

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.

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

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.

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.

Randy