Yep -----Original Message----- From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Chris Murphy Sent: Wednesday, July 11, 2012 9:48 AM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: Re: Apple Petition
Honestly, if I could just enter a FQDN for an Apple TV or a printer I'd be ecstatic. -Chris On Jul 11, 2012, at 9:43 AM, Danner, Mearl wrote: > But it's still link-local and requires management of an enterprise-wide flat > VLAN architecture. No IP addresses I can see. Just the hardware address. > > Don't we want something IP based similar to dynamic DNS? Microsoft provided > WINS and then Active Directory to allow their OSes to move from local subnet > broadcast based discovery. Novell used SLP when they moved from IPX to IP. > > Don't we want Apple to provide us with something similar? > > Mearl > > -----Original Message----- > From: The EDUCAUSE Wireless Issues Constituent Group Listserv > [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Kellogg, Brian D. > Sent: Tuesday, July 10, 2012 8:03 PM > To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU > Subject: Re: [WIRELESS-LAN] Apple Petition > > I might be misunderstanding something; if so please correct me. When I setup > a Linux MDNS server the bonjour devices all auto registered with the DNS > server so there were no entries I had to manually create. I used a subdomain > to keep them from cluttering up the our root domain for all bonjour devices, > but I only tested with a handful of devices and found that some devices would > not query MDNS for the resource records. > > -Brian > ________________________________________ > From: The EDUCAUSE Wireless Issues Constituent Group Listserv > [WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Johnson, Neil M > [neil-john...@uiowa.edu] > Sent: Tuesday, July 10, 2012 8:41 PM > To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU > Subject: Re: Apple Petition > > My concern is that certain fields appear to contain dynamic information like > the software version (see "srcvers=120.2) and other information (what does > "35CF2488F02660B1" mean ?). > > The only way it seems to collect this information is to connect the device to > local net, run Bonjour Browser or run "dns-sd -Z" command on a MAC and copy > and paste results into your DNS configs. > > If certain data is dynamic then, you are out of luck. > > -Neil > > -- > Neil Johnson > Network Engineer > The University of Iowa > Phone: 319 384-0938 > Fax: 319 335-2951 > Mobile: 319 540-2081 > E-Mail: neil-john...@uiowa.edu > > > From: Joel Coehoorn <jcoeho...@york.edu<mailto:jcoeho...@york.edu>> > Reply-To: The EDUCAUSE Wireless Issues Constituent Group Listserv > <WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> > Date: Tuesday, July 10, 2012 7:22 PM > To: > "WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>" > > <WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> > Subject: Re: [WIRELESS-LAN] Apple Petition > > If those entries work, and are all that is needed, then we're not far from > full support. It seems like we could get a tool or set of scripts to automate > creating/modifying the needed records. > > Sent from my iPad > > On Jul 10, 2012, at 7:11 PM, "Johnson, Neil M" > <neil-john...@uiowa.edu<mailto:neil-john...@uiowa.edu>> wrote: > > We looked into DNS-SD, but with entries like this (example taken from an > earlier e-mail from Oscar Silva at the Univ. or Texas , and confirmed by our > own testing): > > > _airplay._tcp PTR utnet-appletv._airplay._tcp > > > > utnet-appletv._airplay._tcp SRV 0 0 7000 > utnet-appletv.bonjour.utexas.edu<http://utnet-appletv.bonjour.utexas.edu>. ; > Replace with unicast FQDN of target host > > utnet-appletv._airplay._tcp TXT "deviceid=28:E7:CF:DB:6E:E0" > "features=0x39f7" "model=AppleTV2,1" "pw=1" "srcvers=120.2" > > > > _raop._tcp PTR > 28E7CFDB6EE0@utnet-appletv._raop._tcp<mailto:28E7CFDB6EE0@utnet-appletv._raop._tcp> > > > > 28E7CFDB6EE0@utnet-appletv._raop._tcp<mailto:28E7CFDB6EE0@utnet-appletv._raop._tcp> > SRV 0 0 49152 > utnet-appletv.bonjour.utexas.edu<http://utnet-appletv.bonjour.utexas.edu>. ; > Replace with unicast FQDN of target host > > 28E7CFDB6EE0@utnet-appletv._raop._tcp<mailto:28E7CFDB6EE0@utnet-appletv._raop._tcp> > TXT "txtvers=1" "ch=2" "cn=0,1,2,3" "da=true" "et=0,3" "md=0,1,2" "pw=true" > "sv=false" "sr=44100" "ss=16" "tp=UDP" "vn=65537" "vs=120.2" "am=AppleTV2,1" > "sf=0x4" > > > > _appletv-v2._tcp PTR 35CF2488F02660B1._appletv-v2._tcp > > 35CF2488F02660B1._appletv-v2._tcp SRV 0 0 3689 utnet- > > appletv.bonjour.utexas.edu<http://appletv.bonjour.utexas.edu>. ; Replace with > unicast FQDN of target host > > > 35CF2488F02660B1._appletv-v2._tcp TXT "txtvers=1" > "hG=00000000-06f6-4f5d-0171-0bcc51d34d14" "MniT=167845888" "fs=2" > "Name=utnet-appletv" "PrVs=65538" "DFID=2" "EiTS=1" "MiTPV=196611" > > > > _sleep-proxy._udp PTR 70-35-60-63\032utnet-appletv._sleep-proxy._udp > > > > 70-35-60-63\032utnet-appletv._sleep-proxy._udp SRV 0 0 55597 > utnet-appletv.bonjour.utexas.edu<http://utnet-appletv.bonjour.utexas.edu>. ; > Replace with unicast FQDN of target host > > 70-35-60-63\032utnet-appletv._sleep-proxy._udp TXT "" > > > > required for every Apple TV (and no direction from Apple on what > entries/fields are actually required) our DNS admins were ready with pitch > forks and torches if we attempted saddle them with the the responsibility of > trying to maintain records for 100's such devices (not to mention printers, > etc.). > > -Neil > > -- > Neil Johnson > Network Engineer > The University of Iowa > Phone: 319 384-0938 > Fax: 319 335-2951 > Mobile: 319 540-2081 > E-Mail: neil-john...@uiowa.edu<mailto:neil-john...@uiowa.edu> > > > From: Garry Peirce <pei...@maine.edu<mailto:pei...@maine.edu>> > Reply-To: "pei...@maine.edu<mailto:pei...@maine.edu>" > <pei...@maine.edu<mailto:pei...@maine.edu>> > Date: Tuesday, July 10, 2012 10:15 AM > To: > "WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>" > > <WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> > Subject: Re: [WIRELESS-LAN] Apple Petition > > I'm in support of the collective request to help enable further operational > flexibility, although also not sure Apple will feel enough pressure to assist. > > To the first item: 'That Apple establish a way for Apple TV's (and other > Bonjour/Airplay enabled devices) be accessible across multiple IPv4 and IPv6 > sub-nets." > Isn't this item solved to a degree by wide area DNS-SD? > If not, I assume this is left open to solve by either making it use a > routable mcast addr or by creating some non-standard solution. > > Controls will be needed to make sense of all the advertised services and > possibly for security/privacy reasons. > I would think navigating a large Bonjour enabled subnet for a production > service must be an ugly exercise - nevermind if enabled to pass L2 boundaries. > Who remembers those IPX service filtering ACLs? Request #2 might soon follow > to network vendors to be able to support Bonjour service filtering. > > For production services, wide area DNS-SD seems a better tool to me, as > opposed to using the wild west of zeroconf end device advertisements or some > special hardware solution. We've trialed it (static entries) for printing > and it seems to work well. > This leverages our existing DNS infrastructure, allows for control of the > advertised entries, and a uniform naming convention making it easier to > identify the service. > One could also opt to block 224.0.0.251 altogether, if there is concern about > unnecessary device traffic. > > So in tandem to supporting this request, I'd also be interested in anyone's > recap of their wide area DNS-SD (WAB) environment, the services being > advertised , how it is scaling, and any major stumbling blocks. > > > From: The EDUCAUSE Wireless Issues Constituent Group Listserv > [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Lee H Badman > Sent: Monday, July 09, 2012 4:00 PM > To: > WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> > Subject: Re: [WIRELESS-LAN] Apple Petition > > Please consider this- as we get to the point where we have an agreed on > document, say by this Friday, and we find an online petition site to use > where individuals can "sign" on in whatever form that takes before we close > the signing window and present it to Apple- are each one of us able to do so > on behalf of our institutions or organizations? If you need to seek > permission, now is the time. If a CIO or Director is the only one allowed to > make such public-facing declarations on behalf of your school/or org, it > would be good to start working the notion. Ideally, no one would overstep > their position by jumping on this worthy endeavor. > > Lee H. Badman > Wireless Architect/Network Engineer > Information Technology and Services > Adjunct Instructor, iSchool > Syracuse University > 315 443-3003 > > > From: The EDUCAUSE Wireless Issues Constituent Group Listserv > [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU]<mailto:[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU]>On > Behalf Of Andy Voelker > Sent: Monday, July 09, 2012 12:44 PM > To: > WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> > Subject: Re: [WIRELESS-LAN] Apple Petition > > That confuses me as well. It is obviously built in to many other iOS devices > (iPod Touch, iPad) and has been for some time. Why the change? I suspect it > just due to the GUI difference. If so, that's easily fixable. > > -- Andy Voelker > Manager of Student Computing in the Technology Commons > WCU Staff Senator > Western Carolina University > Check the status of your IT requests at any time at http://help.wcu.edu/ ! > > From: The EDUCAUSE Wireless Issues Constituent Group Listserv > [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU]<mailto:[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU]>On > Behalf Of Voll, Toivo > Sent: Friday, July 06, 2012 1:28 PM > To: > WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> > Subject: Re: [WIRELESS-LAN] Apple Petition > > Also, for me, the lack of support for WPA2-Enterprise is a head-scratcher. If > they go through the trouble of supporting the rest of the encryption schemes, > and obviously support it on a bunch of their other products, why randomly > leave it out of some products? I'd prioritize that a bit more, personally. > > -- > Toivo Voll > Network Engineer > Information Technology Communications > University of South Florida > > > ********** Participation and subscription information for this EDUCAUSE > Constituent Group discussion list can be found at > http://www.educause.edu/groups/. > > ********** Participation and subscription information for this EDUCAUSE > Constituent Group discussion list can be found at > http://www.educause.edu/groups/. > > ********** Participation and subscription information for this EDUCAUSE > Constituent Group discussion list can be found at > http://www.educause.edu/groups/. > > ********** Participation and subscription information for this EDUCAUSE > Constituent Group discussion list can be found at > http://www.educause.edu/groups/. > > ********** > Participation and subscription information for this EDUCAUSE Constituent > Group discussion list can be found at http://www.educause.edu/groups/. > > ********** > Participation and subscription information for this EDUCAUSE Constituent > Group discussion list can be found at http://www.educause.edu/groups/. =========================================== Chris Murphy Network Engineer MIT Information Services & Technology Room W92-191 77 Massachusetts Avenue Cambridge, MA 02139 ch...@mit.edu ********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/. ********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.
