From sacadmin Thu Jul 2 03:22:59 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n62AMxHi007159 for ; Thu, 2 Jul 2009 03:22:59 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n62AMpr9010209 for <@sunmail2sca.sfbay.sun.com:PSARC@sun.com>; Thu, 2 Jul 2009 11:22:58 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KM500501GU83900@nwk-avmta-1.sfbay.Sun.COM> for PSARC@sun.com (ORCPT PSARC@Sun.COM); Thu, 02 Jul 2009 03:22:56 -0700 (PDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KM5001WWGU7CQB0@nwk-avmta-1.sfbay.Sun.COM> for PSARC@sun.com (ORCPT PSARC@Sun.COM); Thu, 02 Jul 2009 03:22:56 -0700 (PDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-1-fe3.eu.sun.com [192.18.6.10]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n62AMsWB006342 for ; Thu, 02 Jul 2009 10:22:54 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KM500K00F4BC700@fe-emea-10.sun.com> for PSARC@Sun.COM (ORCPT PSARC@Sun.COM); Thu, 02 Jul 2009 11:22:54 +0100 (BST) Received: from [129.156.173.215] ([unknown] [129.156.173.215]) by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KM500GV9GTZ3E30@fe-emea-10.sun.com> for PSARC@Sun.COM (ORCPT PSARC@Sun.COM); Thu, 02 Jul 2009 11:22:47 +0100 (BST) Date: Thu, 02 Jul 2009 11:23:05 +0100 From: Stacey Jonathan Marshall Subject: update libresolv to ISC_6.0_p1b. PSARC 2009/370 Sender: Stacey.Marshall@sun.com To: PSARC@sun.com Message-id: <4A4C8A89.9040303@sun.com> Organization: Solaris RPE MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 User-Agent: Thunderbird 2.0.0.21 (X11/20090323) Status: RO Content-Length: 14556 For the case record. -------- Original Message -------- Subject: Re: update libresolv to ISC_6.0_p1b. 2009/370 Date: Mon, 29 Jun 2009 16:16:27 +0100 From: Stacey Jonathan Marshall Organization: Solaris RPE To: Rao Shoaib , PSARC-ext@sun.com CC: stacey.marshall@SUN.com References: <4A43F3BF.9090407@sun.com> Hi Rao, I noticed a few issues which in part seem to be a confusion or contamination from PSARC 2009/308 See in-line comments for details.. I'm looking forward to seeing this work completed. Regards, Stacey On 25/06/2009 23:01, Rao Shoaib wrote: > I am submitting this one pager on behalf of Ed Posnak > (ed.posnak@gmail.com) as Ed does not have SWAN access and could not > submit it. > > Rao. > ------------------------------------------------------------------------ > > Template Version: @(#)onepager.txt 1.31 07/08/08 SMI > > This information is Copyright 2009 Sun Microsystems > > 1. Introduction > 1.1. Project/Component Working Name: > BIND Update to ISC libbind-6.0 > Should be "Update libresolv to ISC libbind-6.0" > 1.2. Name of Document Author/Supplier: > Ed Posnak > > 1.3. Date of This Document: > 6/25/2009 > > 1.4. Name of Major Document Customer(s)/Consumer(s): > 1.4.1. The Community you expect to review your project: > Solaris PAC > > 1.4.2. The ARC(s) you expect to review your project: > PSARC > > 1.4.3. The Director/VP who is "Sponsoring" this project: > greg.lavender@sun.com > > 1.4.4. The name of your business unit: > Solaris Networking > > 1.5. Email Aliases: > 1.5.1. Responsible Manager: Victor.Nelson@sun.com > 1.5.2. Responsible Engineer: ed.posnak@gmail.com > 1.5.3. Marketing Manager: Jeff.McMeekin@Sun.COM > 1.5.4. Interest List: bind-iteam-ext@sun.com > > 2. Project Summary > 2.1. Project Description: > > Provide latest and most up-to-date version of Internet Systems > Consortium (ISC) BIND in Solaris Operating Environment. > > Customer requirements and bug reports have driven the need for an updated > version of BIND. The above two paragraphs are not accurate, what this project does is: > The resolver library, libresolv2, is currently based on > a mixture of ISC versions from around 2001 and it is desired to upgrade > them to version 6.0, which was released in 2009. > > Sun has made several changes to the ISC code, many of which are not > incorporated into the latest ISC release, and thus must be applied to the > new code. In the previous port, source code changes were liberally > applied and documentation was not kept up to date, making the task of > upgrading to a new ISC release unnecessarily complicated. > I don't believe the above paragraph is quite right. As I recall much of the Sun changes were incorporated by ISC while some have not. For example see 6485024 "Solaris res_ninit() undocumented short-circuit trips up other applications" > A goal of this project is to minimize the amount of effort required in > future upgrades by (1) getting the Solaris code as close to the ISC code > as possible and (2) fully and accurately documenting the set of changes > that will need to be carried forward into future upgrades. This involves > eliminating source code changes that are unncessary and finding ways to > accomplish the original goal without modifying the source code. > Documenting Sun's changes involves first enumerating all changes that > were made to ISC source code, then determining which changes have already > been incorporated into ISC's code base, and of those that haven't, > identifying the ones that need to be applied and carried forward. We will > continue to submit our changes to ISC so that they may be incorporated > into a future ISC release; others will need to be applied in future > ports. We are striving to make this set of changes as small as possible > and to document it well. > > Whereas it is a goal of this project to make the libresolv2 source tree > more closely resemble the ISC source tree, it is a requirement for the > new libresolv.so.2 to be binary compatible with the previous version. > Thus we will do as much as possible within the limits of binary > compatibility to minimize changes to the ISC code. > > The primary deliverables are: > 1. Source code that matches ISC code more closely and > 2. A complete, up-to-date list of changes that Sun must retain going > forward > > Other deliverables include: > 1. Strategy and assumptions documents > 2. Suite of unit tests targeting Sun's changes and general functionality > 3. Test plan and test results documents > > 2.2. Risks and Assumptions: > > The risk of introducing defect is high because the changes that we are > applying were originally made to code that has evolved significantly over > the course of several years. This risk is further increased by > workarounds that are necessary to meet the requirement for binary > compatibility. Moreover, we do not have any unit tests for libresolv2. > > To mitigate the risk of introducing defects we are developing a suite of > unit tests consisting of two types: tests for each of the > Solaris-specific changes and general tests of the public interface. The > Solaris-specific tests will give us confidence that our changes work as > advertised, and the general tests will give us confidence that our > changes did not break anything in the ISC code. > > (For details see our Strategy and assumptions documents: > http://opensolaris.org/os/project/bind/BINDPortingStrategy-v0.5.doc > http://opensolaris.org/os/project/bind/BINDPortingAssumptions-v0.3.doc ) > > > 2.3. Release Binding > > The Required release binding is Patch. Revenue Product Engineering will > back-port to Solaris 10 and possibly older sustained gates if security > issues necessitate. > *"will"* might be a bit strong for libresolv, a *"may"* would be more accurate. > 3. Business Summary > 3.1. Problem Area: > Solaris includes libresolv2 for DNS services, and it's broadly used > across many customer types. > > The current libresolv2 is based on source code that is 8-9 years old. > > > Advancements in the DNSSEC protocol have provided new Resource Record > NSEC3 [RFC 5155] and associated protocol which unlike its predecessor > NSEC can not be used to effectivly discover the whole domain. > The above paragraph is not suited for this one-pager as libbind does not provide DNSSEC functionality. > 3.2. Market/Requester: > > Solaris customers broadly > > 3.3. Business Justification: > > The current version of libresolv2 in Solaris is woefully outdated and > is in-fact now deemed EOL by ISC. > > By being up-to-date with the ISC version Sun is better able to provide > ISC security fixes swiftly. Newer versions also contain other bug fixes > and enhancements that many customers value. > > 3.4. Competitive Analysis: > Most OS's are shipping latest ISC code. > > > 3.5. Opportunity Window/Exposure: > N/A. > > 3.6. How will you know when you are done?: > > The updated libresolv2 library has been code reviewed, any comments have > been incorporated, and the updated version passes all unit tests. > > 4. Technical Description: > 4.1. Details: > > The first phase of this project will involve identifying the set of > existing changes to ISC code that were made by Sun. By comparing > libresolv to the ISC source code on which it was based, a list of > existing changes will be created and documented. Changes will be > categorized as to whether they are already implemented in ISC libbind, > not implemented, obsolete, or not wanted and whether they are inherent to > Solaris or could be submitted to ISC for inclusion in a future release. > > (See http://opensolaris.org/os/project/bind/ > BINDExistingChangesLists-libresolv2-v0.4.doc) > > In the second phase, all changes in the "not implemented" category will > be applied to the new ISC libbind source code. If the change is not > inherent to Solaris it will be submitted to ISC for inclusion in a future > release. Other changes may be necessary to accommodate the evolution in > the ISC code over several years. An up-to-date list of changes > implemented will be maintained. > > (See: > http://opensolaris.org/os/project/bind/BINDInterfaceChangesImplemented.doc > http://cr.opensolaris.org/~posnake/libresolv2-v0.5/ > http://cr.opensolaris.org/~posnake/public-headers-v0.4/ ) > > The third phase involves development and running of unit tests. A > specific unit test will be developed for each change that Sun makes to > the ISC source code. Moreover, unit tests will be developed to test the > public interface of libresolv2. > > (See http://opensolaris.org/os/project/bind/ > stcnv-libresolv2-src-2009-06-25.tar.bz2 ) > > > 4.2. Bug/RFE Number(s): > > - 6811100 Provide BIND 9.6.0 > CR 6811100 is being used to update BIND in the SFW gate. The CR that this ARC request is for is: 6289479 libresolv2 should be cleaned up Some other open CR's may also be addressed. > 4.3. In Scope: > > Updating the libresolv2 library to the latest version of ISC > libbind. > > 4.4. Out of Scope: > > - 6626959 DNS resolver specifies EDNS0 UDP payload size of zero > 6626959 is a BIND issue, not libresolv. > - 6541618 nscd coredumps in libresolv.so.2`__ns_samename > - 6289479 libresolv2 should be cleaned up > - 6485024 Solaris res_ninit() undocumented short-circuit > trips up other applications > 6541618 and 6485024 would most likely be addressed by this project. > - 6790669 BIND should ship example configuration and zone > files. > ok. > - 6686630 nslookup dumps core under certain conditions: > mem.c:877: INSIST(ctx->stats[i].gets == 0U) failed. > - 6680248 nslookup causes DNS request flood with certain > /etc/resolv.conf > - 6635218 S10 nslookup set debug does not show the search > list in resolv.conf > - 4636386 nslookup return same code if site is found/not found > - 6218253 SUNWbindr's upgrade attempt fails > - 6822736 Provide BIND 9 Sun Cryptographic Accelerator support > - 6710052 Bind should be delivering also sun4v optimized > version by default > - 4761436 Customer requests in.named to be installed to > run as non-root user. > Some of the above *may* be addressed by PSARC 2009/308 > Integrate BIND 9 test suite into STC2. > Presume that should read "Integrate *libresolv* test suite into STC2". > 4.5. Interfaces: > > The API/ABI of libresolv2 will not be changed in an incompatible way. > > Additions will be made to the following public header files: > /usr/include/netdb.h > /usr/include/resolv.h > /usr/include/arpa/inet.h > /usr/include/arpa/nameser.h > > See http://cr.opensolaris.org/~posnake/public-headers-v0.4/ > > 4.6. Doc Impact: > > RESOLVER(3RESOLV) and its aliases: > res_ninit > res_ourserver_p > fp_resstat > res_hostalias > res_pquery > res_nquery > res_nsearch > res_nquerydomain > res_nmkquery > res_nsend > res_nupdate > res_nmkupdate > res_nclose > res_nsendsigned > res_findzonecut > res_getservers > res_setservers > res_ndestroy > dn_comp > dn_expand > hstrerror > res_init > res_isourserver > fp_nquery > p_query > fp_query > hostalias > res_query > res_search > res_querydomain > res_mkquery > res_send > res_update > res_close > herror > > TSIG(3RESOLV) and its aliases: > ns_sign > ns_sign_tcp > ns_sign_tcp_init > ns_verify > ns_verify_tcp > ns_verify_tcp_init > ns_find_tsig > > INET_CIDR(3RESOLV) and its aliases: > inet_cidr_ntop > inet_cidr_pton > > 4.7. Admin/Config Impact: None. > > 4.8. HA Impact: > None. > 4.9. I18N/L10N Impact: > None. > > 4.10. Packaging & Delivery: > The updated SUNWcslr package will be delivered to ON > > 4.11. Security Impact: > > NSEC3 supported. > None. > 4.12. Dependencies: > None. > > 5. Reference Documents: > http://opensolaris.org/os/project/bind/BINDPortingStrategy-v0.5.doc > http://opensolaris.org/os/project/bind/BINDPortingAssumptions-v0.3.doc > http://opensolaris.org/os/project/bind/BINDExistingChangesLists-libresolv2-v0.4.doc > http://opensolaris.org/os/project/bind/BINDInterfaceChangesImplemented.doc > http://cr.opensolaris.org/~posnake/libresolv2-v0.5/ > http://cr.opensolaris.org/~posnake/public-headers-v0.4/ > http://opensolaris.org/os/project/bind/stcnv-libresolv2-src-2009-06-25.tar.bz2 > > 6. Resources and Schedule: > 6.1. Projected Availability: > > July 2009 > > 6.2. Cost of Effort: > 6 weeks, one person engineering, including unit test development, > QA process and documentation. > > 6.4. Product Approval Committee requested information: > 6.4.1. Consolidation or Component Name: > ON > 6.4.7. Target RTI Date/Release: > July 2009 > 6.4.8. Target Code Design Review Date: > July 2009 > 6.5. ARC review type: FastTrack > > 6.6. ARC Exposure: open > 6.6.1. Rationale: Part of OpenSolaris > > 7. Prototype Availability: > 7.1. Prototype Availability: > N/A > 7.2. Prototype Cost: > N/A > > From Sebastien.Roy@Sun.COM Tue Aug 18 15:38:23 2009 Received: from dm-sfbay-02.sfbay.sun.com (dm-sfbay-02.SFBay.Sun.COM [129.146.11.31]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7IMcNRU014971 for ; Tue, 18 Aug 2009 15:38:23 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n7IMcN9T031163 for ; Tue, 18 Aug 2009 15:38:23 -0700 (PDT) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n7IMcNqT006454 for ; Tue, 18 Aug 2009 22:38:23 GMT MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KOL00500FRIUD00@mail-amer.sun.com> for psarc-ext@sac.sfbay.sun.com; Tue, 18 Aug 2009 16:38:23 -0600 (MDT) Received: from [129.148.174.103] ([unknown] [129.148.174.103]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KOL00DUQG7V8270@mail-amer.sun.com>; Tue, 18 Aug 2009 16:38:19 -0600 (MDT) Date: Tue, 18 Aug 2009 18:36:29 -0400 From: Sebastien Roy Subject: update libresolv to ISC_6.0_p1b [PSARC/2009/370 FastTrack timeout 08/25/2009] Sender: Sebastien.Roy@Sun.COM To: psarc-ext Cc: Ed Posnak , "Rao.Shoaib" Message-id: <1250634989.10348.153.camel@strat> Organization: Sun Microsystems X-Mailer: Evolution 2.26.2 Status: RO Content-Length: 6150 I'm sponsoring this fasttrack for Ed Posnak , it times out on 08/25/2009. This project proposes to update libresolv(3LIB)/libresolv.so.2 to ISC libbind 6.0. Release binding: minor. Current Solaris libresolv.so.2 is based on ISC code circa 2003 with Solaris specific changes. Over time the library has diverged from the ISC code and it is non trivial to update it with latest ISC code. This project will move Solaris code closer to ISC code while maintaining API/ABI compatability. The changes that were made to ISC code in the previous port have been categorized and analyzed[1]. Changes for this port have been documented[2], as well as our strategy and assumptions for maintaining API/ABI compatibility[3,4]. Changes that are not inherent to Solaris will be submitted to ISC for inclusion in a future release. Another project (PSARC/2009/308) is updating BIND components to the latest ISC code. There are no dependencies between the two projects. Interfaces: The API/ABI of libresolv(3LIB)/libresolv.so.2 will not be changed in any incompatible way. The changes to public interfaces are as following: New Exported Interfaces |______________________________________________________________________| | Interface | Classification | Modifier/Comments | |______________________|_______________________|_______________________| | | | | | res_rndinit | Volatile | Undocumented | | res_nrandomid | Volatile | Undocumented | | res_nopt_rdata | Volatile | Undocumented | | ns_parserr2 | Volatile | Undocumented | | ns_name_length | Volatile | Undocumented | | ns_name_eq | Volatile | Undocumented | | ns_name_owned | Volatile | Undocumented | | ns_name_map | Volatile | Undocumented | | ns_name_labels | Volatile | Undocumented | | ns_newmsg_init | Volatile | Undocumented | | ns_newmsg_copy | Volatile | Undocumented | | ns_newmsg_id | Volatile | Undocumented | | ns_newmsg_flag | Volatile | Undocumented | | ns_newmsg_q | Volatile | Undocumented | | ns_newmsg_rr | Volatile | Undocumented | | ns_newmsg_done | Volatile | Undocumented | | ns_rdata_unpack | Volatile | Undocumented | | ns_rdata_equal | Volatile | Undocumented | | ns_rdata_refers | Volatile | Undocumented | | inet_cidr_ntop | Volatile | Undocumented | | inet_cidr_ntop | Volatile | Undocumented | | inet_nsap_addr | Volatile | Undocumented | | inet_nsap_ntoa | Volatile | Undocumented | | inet_cidr_pton | Volatile | Documented[5] | | inet_neta | Volatile | Documented[5] | |______________________|_______________________|_______________________| Even though ISC defines the above interfaces in public header files it does not provide any documentation for most of the interfaces. We can not guarantee the semantics and hence we are making no attempt to document these functions. This is similar to what was done in previous update PSARC 1999/662. Following interfaces already exist in Solaris but are undocumented. They are now being documented. New Exported Interfaces |______________________________________________________________________| | Interface | Classification | Modifier/Comments | |______________________|_______________________|_______________________| | | | | | ns_sign | Volatile | Documented[6] | | ns_sign_tcp | Volatile | Documented[6] | | ns_sign_tcp_init | Volatile | Documented[6] | | ns_verify | Volatile | Documented[6] | | ns_verify_tcp | Volatile | Documented[6] | | ns_verify_tcp_init | Volatile | Documented[6] | | ns_find_tsig | Volatile | Documented[6] | |______________________|_______________________|_______________________| All new and old interfaces are available by linking to libresolv(3LIB) or libresolv.so.2 The new libresolv.so.2 provides following additional public types: typedef uchar_t ns_nname[NS_MAXNNAME]; typedef const uchar_t *ns_nname_ct; typedef uchar_t *ns_nname_t; struct ns_namemap { ns_nname_ct base; int len; }; typedef struct ns_namemap *ns_namemap_t; typedef const struct ns_namemap *ns_namemap_ct; struct ns_newmsg { ns_msg msg; const uchar_t *dnptrs[25]; const uchar_t **lastdnptr; }; typedef struct ns_newmsg ns_newmsg; typedef struct __ns_rr2 { ns_nname nname; size_t nnamel; int type; int rr_class; uint_t ttl; int rdlength; const uchar_t *rdata; } ns_rr2; References relative to this case's materials directory: [1] BINDExistingChangesLists-libresolv2-v0.4.pdf [2] BINDInterfaceChangesImplemented.pdf [3] BINDPortingStrategy-v0.5.pdf [4] BINDPortingAssumptions-v0.3.pdf [5] inet_cidr.cat3 [6] tsig.cat3 Note: man pages[5,6] provided with the case material are the ones that are shipped by ISC. Their content will be used to write Solaris man pages in standard solaris format. for example these man pages donot indicate linking with libresolv but Solaris man pages will. From gdamore@sun.com Tue Aug 18 15:51:10 2009 Received: from dm-sfbay-01.sfbay.sun.com (dm-sfbay-01.SFBay.Sun.COM [129.145.155.118]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7IMpAjB015053 for ; Tue, 18 Aug 2009 15:51:10 -0700 (PDT) Received: from sca-es-mail-2.sun.com (sca-es-mail-2.Sun.COM [192.18.43.133]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n7IMpAPh011720 for ; Tue, 18 Aug 2009 15:51:10 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n7IMp5pR002755 for ; Tue, 18 Aug 2009 15:51:05 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KOL00I00GR4Y500@fe-sfbay-09.sun.com> for psarc-ext@sac.sfbay.sun.com; Tue, 18 Aug 2009 15:51:05 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KOL00340GT48SD0@fe-sfbay-09.sun.com>; Tue, 18 Aug 2009 15:51:05 -0700 (PDT) Date: Tue, 18 Aug 2009 15:51:04 -0700 From: "Garrett D'Amore" Subject: Re: update libresolv to ISC_6.0_p1b [PSARC/2009/370 FastTrack timeout 08/25/2009] In-reply-to: <1250634989.10348.153.camel@strat> Sender: Garrett.Damore@sun.com To: Sebastien Roy Cc: psarc-ext , Ed Posnak , "Rao.Shoaib" Message-id: <4A8B3058.8000308@sun.com> References: <1250634989.10348.153.camel@strat> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 6433 +1 - Garrett Sebastien Roy wrote: > I'm sponsoring this fasttrack for Ed Posnak , it > times out on 08/25/2009. > > This project proposes to update libresolv(3LIB)/libresolv.so.2 to > ISC libbind 6.0. > > Release binding: minor. > > Current Solaris libresolv.so.2 is based on ISC code circa 2003 with Solaris > specific changes. Over time the library has diverged from the ISC code and > it is non trivial to update it with latest ISC code. > > This project will move Solaris code closer to ISC code while maintaining > API/ABI compatability. > > The changes that were made to ISC code in the previous port have been > categorized and analyzed[1]. Changes for this port have been documented[2], > as well as our strategy and assumptions for maintaining API/ABI > compatibility[3,4]. Changes that are not inherent to Solaris will be submitted > to ISC for inclusion in a future release. > > Another project (PSARC/2009/308) is updating BIND components to the latest > ISC code. There are no dependencies between the two projects. > > Interfaces: > > The API/ABI of libresolv(3LIB)/libresolv.so.2 will not be changed in any > incompatible way. > The changes to public interfaces are as following: > > New Exported Interfaces > |______________________________________________________________________| > | Interface | Classification | Modifier/Comments | > |______________________|_______________________|_______________________| > | | | | > | res_rndinit | Volatile | Undocumented | > | res_nrandomid | Volatile | Undocumented | > | res_nopt_rdata | Volatile | Undocumented | > | ns_parserr2 | Volatile | Undocumented | > | ns_name_length | Volatile | Undocumented | > | ns_name_eq | Volatile | Undocumented | > | ns_name_owned | Volatile | Undocumented | > | ns_name_map | Volatile | Undocumented | > | ns_name_labels | Volatile | Undocumented | > | ns_newmsg_init | Volatile | Undocumented | > | ns_newmsg_copy | Volatile | Undocumented | > | ns_newmsg_id | Volatile | Undocumented | > | ns_newmsg_flag | Volatile | Undocumented | > | ns_newmsg_q | Volatile | Undocumented | > | ns_newmsg_rr | Volatile | Undocumented | > | ns_newmsg_done | Volatile | Undocumented | > | ns_rdata_unpack | Volatile | Undocumented | > | ns_rdata_equal | Volatile | Undocumented | > | ns_rdata_refers | Volatile | Undocumented | > | inet_cidr_ntop | Volatile | Undocumented | > | inet_cidr_ntop | Volatile | Undocumented | > | inet_nsap_addr | Volatile | Undocumented | > | inet_nsap_ntoa | Volatile | Undocumented | > | inet_cidr_pton | Volatile | Documented[5] | > | inet_neta | Volatile | Documented[5] | > |______________________|_______________________|_______________________| > > Even though ISC defines the above interfaces in public header files it does not > provide any documentation for most of the interfaces. We can not guarantee > the semantics and hence we are making no attempt to document these functions. > This is similar to what was done in previous update PSARC 1999/662. > > Following interfaces already exist in Solaris but are undocumented. They are > now being documented. > > New Exported Interfaces > |______________________________________________________________________| > | Interface | Classification | Modifier/Comments | > |______________________|_______________________|_______________________| > | | | | > | ns_sign | Volatile | Documented[6] | > | ns_sign_tcp | Volatile | Documented[6] | > | ns_sign_tcp_init | Volatile | Documented[6] | > | ns_verify | Volatile | Documented[6] | > | ns_verify_tcp | Volatile | Documented[6] | > | ns_verify_tcp_init | Volatile | Documented[6] | > | ns_find_tsig | Volatile | Documented[6] | > |______________________|_______________________|_______________________| > > > All new and old interfaces are available by linking to libresolv(3LIB) or > libresolv.so.2 > > The new libresolv.so.2 provides following additional public types: > > typedef uchar_t ns_nname[NS_MAXNNAME]; > typedef const uchar_t *ns_nname_ct; > typedef uchar_t *ns_nname_t; > struct ns_namemap { ns_nname_ct base; int len; }; > typedef struct ns_namemap *ns_namemap_t; > typedef const struct ns_namemap *ns_namemap_ct; > struct ns_newmsg { > ns_msg msg; > const uchar_t *dnptrs[25]; > const uchar_t **lastdnptr; > }; > typedef struct ns_newmsg ns_newmsg; > > typedef struct __ns_rr2 { > ns_nname nname; > size_t nnamel; > int type; > int rr_class; > uint_t ttl; > int rdlength; > const uchar_t *rdata; > } ns_rr2; > > > References relative to this case's materials directory: > > [1] BINDExistingChangesLists-libresolv2-v0.4.pdf > [2] BINDInterfaceChangesImplemented.pdf > [3] BINDPortingStrategy-v0.5.pdf > [4] BINDPortingAssumptions-v0.3.pdf > [5] inet_cidr.cat3 > [6] tsig.cat3 > > Note: > man pages[5,6] provided with the case material are the ones that are > shipped by ISC. Their content will be used to write Solaris man pages > in standard solaris format. for example these man pages donot indicate > linking with libresolv but Solaris man pages will. > > > From carlsonj@workingcode.com Tue Aug 18 18:28:47 2009 Received: from dm-sfbay-02.sfbay.sun.com (dm-sfbay-02.SFBay.Sun.COM [129.146.11.31]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7J1Slqs023251 for ; Tue, 18 Aug 2009 18:28:47 -0700 (PDT) Received: from sca-ea-mail-2.sun.com (sca-ea-mail-2.Sun.COM [192.18.43.25]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n7J1SkTs050979 for ; Tue, 18 Aug 2009 18:28:46 -0700 (PDT) Received: from relay15i.sun.com (ip125.net129179-4.block1.us.syntegra.com [129.179.4.125]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n7J17e9p005311 for ; Wed, 19 Aug 2009 01:28:41 GMT Received: from mmp11es.mmp.us.syntegra.com ([160.41.208.11] [160.41.208.11]) by relay15i.sun.com with ESMTP id BT-MMP-356054 for psarc-ext@sac.sfbay.sun.com; Wed, 19 Aug 2009 01:28:39 Z Received: from relay14i.sun.com (relay14i.sun.com [129.179.4.124]) by mmp11es.mmp.us.syntegra.com with ESMTP id BT-MMP-61826120; Wed, 19 Aug 2009 01:28:38 Z Received: from carlson.workingcode.com ([75.150.68.97] [75.150.68.97]) by relay1i.sun.com with ESMTP id BT-MMP-12465547; Wed, 19 Aug 2009 01:28:38 Z Received: from [192.168.254.182] (dhcp-182 [192.168.254.182]) (authenticated bits=0) by carlson.workingcode.com (8.14.2+Sun/8.14.3) with ESMTP id n7J1SPkc016496 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Aug 2009 21:28:25 -0400 (EDT) Message-ID: <4A8B5538.80303@workingcode.com> Date: Tue, 18 Aug 2009 21:28:24 -0400 From: James Carlson User-Agent: Thunderbird 2.0.0.21 (X11/20090323) To: Sebastien Roy CC: psarc-ext , Ed Posnak , "Rao.Shoaib" Subject: Re: update libresolv to ISC_6.0_p1b [PSARC/2009/370 FastTrack timeout 08/25/2009] References: <1250634989.10348.153.camel@strat> In-Reply-To: <1250634989.10348.153.camel@strat> X-Brightmail-Tracker: AAAAAA== X-DCC-dmv.com-Metrics: carlson 1181; Body=4 Fuz1=4 Fuz2=4 X-Antispam: No, score=0.0/5.0, scanned in 0.131sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Status: RO Content-Length: 1577 Sebastien Roy wrote: > | inet_cidr_ntop | Volatile | Undocumented | > | inet_cidr_ntop | Volatile | Undocumented | > | inet_nsap_addr | Volatile | Undocumented | > | inet_nsap_ntoa | Volatile | Undocumented | > | inet_cidr_pton | Volatile | Documented[5] | > | inet_neta | Volatile | Documented[5] | Why are those last two treated the same as the others? They appear to be intended to be used as programming interfaces by ordinary applications, and seem to be useful interfaces. Why should they be marked as "Volatile?" Are they in fact likely to change in incompatible ways? > Even though ISC defines the above interfaces in public header files it does not > provide any documentation for most of the interfaces. We can not guarantee > the semantics and hence we are making no attempt to document these functions. > This is similar to what was done in previous update PSARC 1999/662. That case isn't publicly visible, but at least with the BIND server cases, I recall that we intentionally segregated the interfaces based on how they were documented upstream -- treating undocumented interfaces and those documented not to be used as Volatile (or worse), and the rest as Uncommitted or better. Does Volatile really match with the upstream behavior and the downstream usage? Or is it just a replay of "external?" -- James Carlson 42.703N 71.076W From rao.shoaib@sun.com Tue Aug 18 22:38:14 2009 Received: from jurassic-x4600.sfbay.sun.com (cretaceous.SFBay.Sun.COM [129.146.17.59]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7J5cEPI003922 for ; Tue, 18 Aug 2009 22:38:14 -0700 (PDT) Received: from [10.7.251.159] (punchin-client-10-7-251-159.SFBay.Sun.COM [10.7.251.159]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n7J5cDl5861966; Tue, 18 Aug 2009 22:38:14 -0700 (PDT) Message-ID: <4A8B8FC5.5000507@sun.com> Date: Tue, 18 Aug 2009 22:38:13 -0700 From: Rao Shoaib User-Agent: Thunderbird 2.0.0.17 (X11/20081104) MIME-Version: 1.0 To: James Carlson CC: Sebastien Roy , psarc-ext , Ed Posnak Subject: Re: update libresolv to ISC_6.0_p1b [PSARC/2009/370 FastTrack timeout 08/25/2009] References: <1250634989.10348.153.camel@strat> <4A8B5538.80303@workingcode.com> In-Reply-To: <4A8B5538.80303@workingcode.com> Content-Type: multipart/alternative; boundary="------------010407080008090507070909" Status: RO Content-Length: 5323 This is a multi-part message in MIME format. --------------010407080008090507070909 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit James Carlson wrote: > Sebastien Roy wrote: > >> | inet_cidr_ntop | Volatile | Undocumented | >> | inet_cidr_ntop | Volatile | Undocumented | >> | inet_nsap_addr | Volatile | Undocumented | >> | inet_nsap_ntoa | Volatile | Undocumented | >> | inet_cidr_pton | Volatile | Documented[5] | >> | inet_neta | Volatile | Documented[5] | >> > > Why are those last two treated the same as the others? They appear to > be intended to be used as programming interfaces by ordinary > applications, and seem to be useful interfaces. Why should they be > marked as "Volatile?" Are they in fact likely to change in incompatible > ways? > One goal of this project is to move closer to ISC source base and make merging and updating easier. Since ISC does not guarantee that these interfaces will not change in incompatible ways we do not want to make that guarantee. > >> Even though ISC defines the above interfaces in public header files it does not >> provide any documentation for most of the interfaces. We can not guarantee >> the semantics and hence we are making no attempt to document these functions. >> This is similar to what was done in previous update PSARC 1999/662. >> > > That case isn't publicly visible, but at least with the BIND server > cases, I recall that we intentionally segregated the interfaces based on > how they were documented upstream -- treating undocumented interfaces > and those documented not to be used as Volatile (or worse), and the rest > as Uncommitted or better. > > Does Volatile really match with the upstream behavior and the downstream > usage? Or is it just a replay of "external?" > I am not aware of any ISC interface classification scheme, so how was it figured out which interfaces ISC will not change. In fact ISC has changed some interfaces in incompatible ways and for this update we have to implement workarounds to provide backward compatibility and we do not want to keep doing that. Your assumption about volatile being a replay on external is correct. Rao. --------------010407080008090507070909 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit James Carlson wrote: 
Sebastien Roy wrote:
  
 | inet_cidr_ntop       | Volatile              | Undocumented          |
 | inet_cidr_ntop       | Volatile              | Undocumented          |
 | inet_nsap_addr       | Volatile              | Undocumented          |
 | inet_nsap_ntoa       | Volatile              | Undocumented          |
 | inet_cidr_pton       | Volatile              | Documented[5]         |
 | inet_neta            | Volatile              | Documented[5]         |
    

Why are those last two treated the same as the others?  They appear to
be intended to be used as programming interfaces by ordinary
applications, and seem to be useful interfaces.  Why should they be
marked as "Volatile?"  Are they in fact likely to change in incompatible
ways?
One goal of this project is to move closer to ISC source base and make merging and updating easier. Since ISC does not guarantee that these interfaces will not change in incompatible ways we do not want to make that guarantee.
  
Even though ISC defines the above interfaces in public header files it does not
provide any documentation for most of the interfaces. We can not guarantee 
the semantics and hence we are making no attempt to document these functions.
This is similar to what was done in previous update PSARC 1999/662.
    

That case isn't publicly visible, but at least with the BIND server
cases, I recall that we intentionally segregated the interfaces based on
how they were documented upstream -- treating undocumented interfaces
and those documented not to be used as Volatile (or worse), and the rest
as Uncommitted or better.

Does Volatile really match with the upstream behavior and the downstream
usage?  Or is it just a replay of "external?"
I am not aware of any ISC interface classification scheme, so how was it figured out which interfaces ISC will not change. In fact ISC has changed some interfaces in incompatible ways and for this update we have to implement workarounds to provide backward compatibility and we do not want to keep doing that. Your assumption about volatile being a replay on external is correct.

Rao.


--------------010407080008090507070909-- From carlsonj@workingcode.com Wed Aug 19 06:39:40 2009 Received: from dm-sfbay-01.sfbay.sun.com (dm-sfbay-01.SFBay.Sun.COM [129.145.155.118]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7JDdexJ025851 for ; Wed, 19 Aug 2009 06:39:40 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n7JDdeIL004580 for ; Wed, 19 Aug 2009 06:39:40 -0700 (PDT) Received: from relay13i.sun.com (ip123.net129179-4.block1.us.syntegra.com [129.179.4.123]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n7JDcw91004251 for ; Wed, 19 Aug 2009 13:39:39 GMT Received: from mmp13es.mmp.us.syntegra.com ([160.41.208.13] [160.41.208.13]) by relay13i.sun.com with ESMTP id BT-MMP-482801 for psarc-ext@sac.sfbay.sun.com; Wed, 19 Aug 2009 13:39:39 Z Received: from relay11i.sun.com (relay11i.sun.com [129.179.4.121]) by mmp13es.mmp.us.syntegra.com with ESMTP id BT-MMP-67002084; Wed, 19 Aug 2009 13:39:29 Z Received: from carlson.workingcode.com ([75.150.68.97] [75.150.68.97]) by relay1i.sun.com with ESMTP id BT-MMP-2017453; Wed, 19 Aug 2009 13:39:29 Z Received: from [10.50.24.188] (gate.abinitio.com [65.170.40.132]) (authenticated bits=0) by carlson.workingcode.com (8.14.2+Sun/8.14.3) with ESMTP id n7JDdRMb000333 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 Aug 2009 09:39:27 -0400 (EDT) Message-ID: <4A8C008F.7000301@workingcode.com> Date: Wed, 19 Aug 2009 09:39:27 -0400 From: James Carlson User-Agent: Thunderbird 2.0.0.22 (X11/20090605) To: Rao Shoaib CC: Sebastien Roy , psarc-ext , Ed Posnak Subject: Re: update libresolv to ISC_6.0_p1b [PSARC/2009/370 FastTrack timeout 08/25/2009] References: <1250634989.10348.153.camel@strat> <4A8B5538.80303@workingcode.com> <4A8B8FC5.5000507@sun.com> In-Reply-To: <4A8B8FC5.5000507@sun.com> X-Brightmail-Tracker: AAAAAA== X-DCC-dmv.com-Metrics: carlson 1181; Body=4 Fuz1=4 Fuz2=4 X-Antispam: No, score=-0.2/5.0, scanned in 6.534sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Status: RO Content-Length: 2415 Rao Shoaib wrote: > James Carlson wrote: >> Sebastien Roy wrote: >> >>> | inet_cidr_ntop | Volatile | Undocumented | >>> | inet_cidr_ntop | Volatile | Undocumented | >>> | inet_nsap_addr | Volatile | Undocumented | >>> | inet_nsap_ntoa | Volatile | Undocumented | >>> | inet_cidr_pton | Volatile | Documented[5] | >>> | inet_neta | Volatile | Documented[5] | >>> >> >> Why are those last two treated the same as the others? They appear to >> be intended to be used as programming interfaces by ordinary >> applications, and seem to be useful interfaces. Why should they be >> marked as "Volatile?" Are they in fact likely to change in incompatible >> ways? >> > One goal of this project is to move closer to ISC source base and make > merging and updating easier. That's assumed. > Since ISC does not guarantee that these > interfaces will not change in incompatible ways we do not want to make > that guarantee. Are there any interfaces for which they make that guarantee? If there aren't any, then I suspect that the wrong test is being applied. Where in the documentation is it made clear that these things are effectively unusable? >> Does Volatile really match with the upstream behavior and the downstream >> usage? Or is it just a replay of "external?" >> > I am not aware of any ISC interface classification scheme, so how was it > figured out which interfaces ISC will not change. In fact ISC has > changed some interfaces in incompatible ways and for this update we have > to implement workarounds to provide backward compatibility and we do not > want to keep doing that. I think that's a mistake. There's no free lunch here. Either someone (ISC or OpenSolaris) provides compatibility, or applications will simply break. As the latter is clearly an unacceptable result, it means that future projects should be told by the ARC that they must not use this software. If that's the case, then why bother integrating at all? Does ISC really break documented interfaces in this way? Do you have specifics to share? > Your assumption about volatile being a replay > on external is correct. In that case, this is an error. -- James Carlson 42.703N 71.076W From rao.shoaib@sun.com Wed Aug 19 07:38:06 2009 Received: from jurassic-x4600.sfbay.sun.com (cretaceous.SFBay.Sun.COM [129.146.17.63]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7JEc6XQ026766 for ; Wed, 19 Aug 2009 07:38:06 -0700 (PDT) Received: from [10.7.251.159] (punchin-client-10-7-251-159.SFBay.Sun.COM [10.7.251.159]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n7JEc1j6918388; Wed, 19 Aug 2009 07:38:01 -0700 (PDT) Message-ID: <4A8C0E48.6010402@sun.com> Date: Wed, 19 Aug 2009 07:38:00 -0700 From: Rao Shoaib User-Agent: Thunderbird 2.0.0.17 (X11/20081104) MIME-Version: 1.0 To: James Carlson CC: Sebastien Roy , psarc-ext , Ed Posnak Subject: Re: update libresolv to ISC_6.0_p1b [PSARC/2009/370 FastTrack timeout 08/25/2009] References: <1250634989.10348.153.camel@strat> <4A8B5538.80303@workingcode.com> <4A8B8FC5.5000507@sun.com> <4A8C008F.7000301@workingcode.com> In-Reply-To: <4A8C008F.7000301@workingcode.com> Content-Type: multipart/alternative; boundary="------------050309050404000401040007" Status: RO Content-Length: 4872 This is a multi-part message in MIME format. --------------050309050404000401040007 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit James Carlson wrote: > > >> Since ISC does not guarantee that these >> interfaces will not change in incompatible ways we do not want to make >> that guarantee. >> > > Are there any interfaces for which they make that guarantee? If there > aren't any, then I suspect that the wrong test is being applied. > Let me recheck and get back to you. > Where in the documentation is it made clear that these things are > effectively unusable? > We can add a warning/note to the man pages of the two newly documented interfaces. > >>> Does Volatile really match with the upstream behavior and the downstream >>> usage? Or is it just a replay of "external?" >>> >>> >> I am not aware of any ISC interface classification scheme, so how was it >> figured out which interfaces ISC will not change. In fact ISC has >> changed some interfaces in incompatible ways and for this update we have >> to implement workarounds to provide backward compatibility and we do not >> want to keep doing that. >> > > I think that's a mistake. > > There's no free lunch here. Either someone (ISC or OpenSolaris) > provides compatibility, or applications will simply break. As the > latter is clearly an unacceptable result, it means that future projects > should be told by the ARC that they must not use this software. If > that's the case, then why bother integrating at all? > > Does ISC really break documented interfaces in this way? Do you have > specifics to share? > Very recently a new member was added to a commonly accessed structure which would have required a recompile. We caught it early enough but that may not be always the case. > >> Your assumption about volatile being a replay >> on external is correct. >> > > In that case, this is an error. > Rao. --------------050309050404000401040007 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit James Carlson wrote: 

  
Since ISC does not guarantee that these
interfaces will not change in incompatible ways we do not want to make
that guarantee.
    

Are there any interfaces for which they make that guarantee?  If there
aren't any, then I suspect that the wrong test is being applied.
Let me recheck and get back to you. 
Where in the documentation is it made clear that these things are
effectively unusable?
We can add a warning/note to the man pages of the two newly documented interfaces.
  
Does Volatile really match with the upstream behavior and the downstream
usage?  Or is it just a replay of "external?"
  
      
I am not aware of any ISC interface classification scheme, so how was it
figured out which interfaces ISC will not change. In fact ISC has
changed some interfaces in incompatible ways and for this update we have
to implement workarounds to provide backward compatibility and we do not
want to keep doing that.
    

I think that's a mistake.

There's no free lunch here.  Either someone (ISC or OpenSolaris)
provides compatibility, or applications will simply break.  As the
latter is clearly an unacceptable result, it means that future projects
should be told by the ARC that they must not use this software.  If
that's the case, then why bother integrating at all?

Does ISC really break documented interfaces in this way?  Do you have
specifics to share?
 Very recently a new member was added to a commonly accessed structure which would have required a recompile. We caught it early enough but that may not be always the case. 
  
Your assumption about volatile being a replay
on external is correct.
    

In that case, this is an error.
Rao.


--------------050309050404000401040007-- From rao.shoaib@sun.com Fri Aug 21 14:42:56 2009 Received: from jurassic-x4600.sfbay.sun.com (cretaceous.SFBay.Sun.COM [129.146.17.63]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7LLguVa021716 for ; Fri, 21 Aug 2009 14:42:56 -0700 (PDT) Received: from [129.146.106.219] (caduceus2.SFBay.Sun.COM [129.146.106.219]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n7LLgtBP807446; Fri, 21 Aug 2009 14:42:55 -0700 (PDT) Message-ID: <4A8F14F7.8020106@sun.com> Date: Fri, 21 Aug 2009 14:43:19 -0700 From: Rao Shoaib User-Agent: Thunderbird 2.0.0.18 (X11/20081215) MIME-Version: 1.0 To: James Carlson CC: Sebastien Roy , psarc-ext , Ed Posnak Subject: Re: update libresolv to ISC_6.0_p1b [PSARC/2009/370 FastTrack timeout 08/25/2009] References: <1250634989.10348.153.camel@strat> <4A8B5538.80303@workingcode.com> <4A8B8FC5.5000507@sun.com> <4A8C008F.7000301@workingcode.com> In-Reply-To: <4A8C008F.7000301@workingcode.com> Content-Type: multipart/alternative; boundary="------------080206060708060107020506" Status: RO Content-Length: 8560 This is a multi-part message in MIME format. --------------080206060708060107020506 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Jim, I have been told that we can ask ISC to maintain backward compatibility for documented interfaces. So we would like to change the classification of all the documented interfaces to Committed. The following tables lists those interfaces. New Committed Interfaces |______________________________________________________________________| | Interface | Classification | Modifier/Comments | |______________________|_______________________|_______________________| | | | | | ns_sign | Committed | Documented[6] | | ns_sign_tcp | Committed | Documented[6] | | ns_sign_tcp_init | Committed | Documented[6] | | ns_verify | Committed | Documented[6] | | ns_verify_tcp | Committed | Documented[6] | | ns_verify_tcp_init | Committed | Documented[6] | | ns_find_tsig | Committed | Documented[6] | | inet_cidr_ntop | Committed | Documented[5] | | inet_cidr_pton | Committed | Documented[5] | | inet_neta | Committed | Documented[5] | |______________________|_______________________|_______________________| Rao. James Carlson wrote: > Rao Shoaib wrote: > >> James Carlson wrote: >> >>> Sebastien Roy wrote: >>> >>> >>>> | inet_cidr_ntop | Volatile | Undocumented | >>>> | inet_cidr_ntop | Volatile | Undocumented | >>>> | inet_nsap_addr | Volatile | Undocumented | >>>> | inet_nsap_ntoa | Volatile | Undocumented | >>>> | inet_cidr_pton | Volatile | Documented[5] | >>>> | inet_neta | Volatile | Documented[5] | >>>> >>>> >>> Why are those last two treated the same as the others? They appear to >>> be intended to be used as programming interfaces by ordinary >>> applications, and seem to be useful interfaces. Why should they be >>> marked as "Volatile?" Are they in fact likely to change in incompatible >>> ways? >>> >>> >> One goal of this project is to move closer to ISC source base and make >> merging and updating easier. >> > > That's assumed. > > >> Since ISC does not guarantee that these >> interfaces will not change in incompatible ways we do not want to make >> that guarantee. >> > > Are there any interfaces for which they make that guarantee? If there > aren't any, then I suspect that the wrong test is being applied. > > Where in the documentation is it made clear that these things are > effectively unusable? > > >>> Does Volatile really match with the upstream behavior and the downstream >>> usage? Or is it just a replay of "external?" >>> >>> >> I am not aware of any ISC interface classification scheme, so how was it >> figured out which interfaces ISC will not change. In fact ISC has >> changed some interfaces in incompatible ways and for this update we have >> to implement workarounds to provide backward compatibility and we do not >> want to keep doing that. >> > > I think that's a mistake. > > There's no free lunch here. Either someone (ISC or OpenSolaris) > provides compatibility, or applications will simply break. As the > latter is clearly an unacceptable result, it means that future projects > should be told by the ARC that they must not use this software. If > that's the case, then why bother integrating at all? > > Does ISC really break documented interfaces in this way? Do you have > specifics to share? > > >> Your assumption about volatile being a replay >> on external is correct. >> > > In that case, this is an error. > > --------------080206060708060107020506 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Jim,

I have been told that we can ask ISC to maintain backward compatibility for documented interfaces. So we would like to change the classification of  all the documented interfaces to Committed.  The following tables lists those interfaces.

 			New Committed Interfaces
 |______________________________________________________________________|
 | Interface		| Classification	| Modifier/Comments	|
 |______________________|_______________________|_______________________|
 |			|			|			|
 | ns_sign		| Committed 		| Documented[6]		|
 | ns_sign_tcp		| Committed		| Documented[6]		|
 | ns_sign_tcp_init     | Committed		| Documented[6]		|
 | ns_verify		| Committed		| Documented[6]		| 
 | ns_verify_tcp	| Committed 		| Documented[6]		|
 | ns_verify_tcp_init	| Committed 		| Documented[6]		|
 | ns_find_tsig		| Committed 		| Documented[6]		|
 | inet_cidr_ntop       | Committed             | Documented[5]         |
 | inet_cidr_pton       | Committed             | Documented[5]         |
 | inet_neta            | Committed             | Documented[5]         |
 |______________________|_______________________|_______________________|
Rao.

James Carlson wrote: 
Rao Shoaib wrote:
  
James Carlson wrote:
    
Sebastien Roy wrote:
  
      
 | inet_cidr_ntop       | Volatile              | Undocumented          |
 | inet_cidr_ntop       | Volatile              | Undocumented          |
 | inet_nsap_addr       | Volatile              | Undocumented          |
 | inet_nsap_ntoa       | Volatile              | Undocumented          |
 | inet_cidr_pton       | Volatile              | Documented[5]         |
 | inet_neta            | Volatile              | Documented[5]         |
    
        
Why are those last two treated the same as the others?  They appear to
be intended to be used as programming interfaces by ordinary
applications, and seem to be useful interfaces.  Why should they be
marked as "Volatile?"  Are they in fact likely to change in incompatible
ways?
  
      
One goal of this project is to move closer to ISC source base and make
merging and updating easier.
    

That's assumed.

  
Since ISC does not guarantee that these
interfaces will not change in incompatible ways we do not want to make
that guarantee.
    

Are there any interfaces for which they make that guarantee?  If there
aren't any, then I suspect that the wrong test is being applied.

Where in the documentation is it made clear that these things are
effectively unusable?

  
Does Volatile really match with the upstream behavior and the downstream
usage?  Or is it just a replay of "external?"
  
      
I am not aware of any ISC interface classification scheme, so how was it
figured out which interfaces ISC will not change. In fact ISC has
changed some interfaces in incompatible ways and for this update we have
to implement workarounds to provide backward compatibility and we do not
want to keep doing that.
    

I think that's a mistake.

There's no free lunch here.  Either someone (ISC or OpenSolaris)
provides compatibility, or applications will simply break.  As the
latter is clearly an unacceptable result, it means that future projects
should be told by the ARC that they must not use this software.  If
that's the case, then why bother integrating at all?

Does ISC really break documented interfaces in this way?  Do you have
specifics to share?

  
Your assumption about volatile being a replay
on external is correct.
    

In that case, this is an error.

--------------080206060708060107020506-- From ceri@submonkey.net Fri Aug 21 15:51:42 2009 Received: from dm-sfbay-02.sfbay.sun.com (dm-sfbay-02.SFBay.Sun.COM [129.146.11.31]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7LMpfGe024983 for ; Fri, 21 Aug 2009 15:51:42 -0700 (PDT) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n7LMpfQQ050058 for ; Fri, 21 Aug 2009 15:51:41 -0700 (PDT) Received: from relay15i.sun.com (ip125.net129179-4.block1.us.syntegra.com [129.179.4.125]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n7LMl8jV025766 for ; Fri, 21 Aug 2009 22:51:41 GMT Received: from mmp11es.mmp.us.syntegra.com ([160.41.208.11] [160.41.208.11]) by relay15i.sun.com with ESMTP id BT-MMP-695494 for psarc-ext@sac.sfbay.sun.com; Fri, 21 Aug 2009 22:51:40 Z Received: from relay14i.sun.com (relay14i.sun.com [129.179.4.124]) by mmp11es.mmp.us.syntegra.com with ESMTP id BT-MMP-3034730 for psarc-ext@sac.sfbay.sun.com; Fri, 21 Aug 2009 22:51:40 Z Received: from scuttle.submonkey.net ([208.111.43.184] [208.111.43.184]) by relay1i.sun.com with ESMTP id BT-MMP-19194425 for psarc-ext@sac.sfbay.sun.com; Fri, 21 Aug 2009 22:51:40 Z Received: from cpc1-cdif1-0-0-cust63.cdif.cable.ntl.com ([81.104.164.64] helo=shrike.submonkey.net) by scuttle.submonkey.net with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1MecxG-0007nK-4h; Fri, 21 Aug 2009 22:51:30 +0000 Received: from ceri by shrike.submonkey.net with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MecxD-000CZT-RM; Fri, 21 Aug 2009 23:51:27 +0100 Date: Fri, 21 Aug 2009 23:51:27 +0100 From: Ceri Davies To: Rao Shoaib Cc: James Carlson , Ed Posnak , psarc-ext Subject: Re: update libresolv to ISC_6.0_p1b [PSARC/2009/370 FastTrack timeout 08/25/2009] Message-ID: <20090821225127.GA53064@submonkey.net> References: <1250634989.10348.153.camel@strat> <4A8B5538.80303@workingcode.com> <4A8B8FC5.5000507@sun.com> <4A8C008F.7000301@workingcode.com> <4A8F14F7.8020106@sun.com> In-Reply-To: <4A8F14F7.8020106@sun.com> X-Brightmail-Tracker: AAAAAA== X-PGP: finger ceri@FreeBSD.org User-Agent: Mutt/1.5.18 (2008-05-17) Sender: Ceri Davies MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="9amGYk9869ThD9tj" Content-Disposition: inline Status: RO Content-Length: 927 --9amGYk9869ThD9tj Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Aug 21, 2009 at 02:43:19PM -0700, Rao Shoaib wrote: > Jim, >=20 > I have been told that we can ask ISC to maintain backward compatibility= =20 > for documented interfaces. So we would like to change the classification= =20 > of all the documented interfaces to Committed. Have ISC agreed to do this? If not, I feel that the change is somewhat premature. Ceri --=20 That must be wonderful! I don't understand it at all. -- Moliere --9amGYk9869ThD9tj Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFKjyTvocfcwTS3JF8RAqzsAKC7ookDTxl08egBPYJle9I35vt3AgCgxSEG J3FJCof0mjXnE+Hnqb85C2I= =3try -----END PGP SIGNATURE----- --9amGYk9869ThD9tj-- From Sebastien.Roy@Sun.COM Sat Aug 22 07:39:56 2009 Received: from dm-sfbay-02.sfbay.sun.com (dm-sfbay-02.SFBay.Sun.COM [129.146.11.31]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7MEdt7K007790 for ; Sat, 22 Aug 2009 07:39:55 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n7MEdsIJ033520 for ; Sat, 22 Aug 2009 07:39:54 -0700 (PDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n7MEdsHE007228 for ; Sat, 22 Aug 2009 14:39:54 GMT MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KOS004008EOYE00@mail-amer.sun.com> for psarc-ext@sac.sfbay.sun.com; Sat, 22 Aug 2009 08:39:54 -0600 (MDT) Received: from [192.168.1.3] ([unknown] [173.76.19.212]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KOS001AB8QHNA20@mail-amer.sun.com>; Sat, 22 Aug 2009 08:39:54 -0600 (MDT) Date: Sat, 22 Aug 2009 10:39:52 -0400 From: Sebastien Roy Subject: Re: update libresolv to ISC_6.0_p1b [PSARC/2009/370 FastTrack timeout 08/25/2009] In-reply-to: <20090821225127.GA53064@submonkey.net> Sender: Sebastien.Roy@Sun.COM To: Ceri Davies Cc: Rao Shoaib , James Carlson , Ed Posnak , psarc-ext Message-id: <1250951992.1497.12.camel@seb> Organization: Sun Microsystems X-Mailer: Evolution 2.26.3 References: <1250634989.10348.153.camel@strat> <4A8B5538.80303@workingcode.com> <4A8B8FC5.5000507@sun.com> <4A8C008F.7000301@workingcode.com> <4A8F14F7.8020106@sun.com> <20090821225127.GA53064@submonkey.net> Status: RO Content-Length: 936 On Fri, 2009-08-21 at 23:51 +0100, Ceri Davies wrote: > On Fri, Aug 21, 2009 at 02:43:19PM -0700, Rao Shoaib wrote: > > Jim, > > > > I have been told that we can ask ISC to maintain backward compatibility > > for documented interfaces. So we would like to change the classification > > of all the documented interfaces to Committed. > > Have ISC agreed to do this? If not, I feel that the change is somewhat > premature. The most important part isn't what ISC agrees to do, but what the project team is willing to guarantee to consumers of the interface. If these are Committed interfaces, then the project team and the entity that delivers the OS need to treat them as such. This means that if the upstream source changes in a way that is counter to that classification, then something must be done to maintain backward compatibility beyond just sucking the upstream sources unmodified. That has been done before... -Seb From rao.shoaib@sun.com Sat Aug 22 09:52:44 2009 Received: from jurassic-x4600.sfbay.sun.com (cretaceous.SFBay.Sun.COM [129.146.17.63]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7MGqiYJ016064 for ; Sat, 22 Aug 2009 09:52:44 -0700 (PDT) Received: from [10.7.251.159] (punchin-client-10-7-251-159.SFBay.Sun.COM [10.7.251.159]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n7MGqf3d947578; Sat, 22 Aug 2009 09:52:41 -0700 (PDT) Message-ID: <4A902259.7040100@sun.com> Date: Sat, 22 Aug 2009 09:52:41 -0700 From: Rao Shoaib User-Agent: Thunderbird 2.0.0.17 (X11/20081104) MIME-Version: 1.0 To: Sebastien Roy CC: Ceri Davies , James Carlson , Ed Posnak , psarc-ext , Stacey Jonathan Marshall Subject: Re: update libresolv to ISC_6.0_p1b [PSARC/2009/370 FastTrack timeout 08/25/2009] References: <1250634989.10348.153.camel@strat> <4A8B5538.80303@workingcode.com> <4A8B8FC5.5000507@sun.com> <4A8C008F.7000301@workingcode.com> <4A8F14F7.8020106@sun.com> <20090821225127.GA53064@submonkey.net> <1250951992.1497.12.camel@seb> In-Reply-To: <1250951992.1497.12.camel@seb> Content-Type: multipart/alternative; boundary="------------070503010102000803030903" Status: RO Content-Length: 3560 This is a multi-part message in MIME format. --------------070503010102000803030903 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sebastien Roy wrote: > On Fri, 2009-08-21 at 23:51 +0100, Ceri Davies wrote: > >> On Fri, Aug 21, 2009 at 02:43:19PM -0700, Rao Shoaib wrote: >> >>> Jim, >>> >>> I have been told that we can ask ISC to maintain backward compatibility >>> for documented interfaces. So we would like to change the classification >>> of all the documented interfaces to Committed. >>> >> Have ISC agreed to do this? If not, I feel that the change is somewhat >> premature. >> > > The most important part isn't what ISC agrees to do, but what the > project team is willing to guarantee to consumers of the interface. If > these are Committed interfaces, then the project team and the entity > that delivers the OS need to treat them as such. This means that if the > upstream source changes in a way that is counter to that classification, > then something must be done to maintain backward compatibility beyond > just sucking the upstream sources unmodified. That has been done > before... > Sun has a contract with ISC and Stacey maintains that relationship. I made changes to interface stability level after Stacey told me that Sun would have a case with ISC if documented interfaces were changed in an incompatible way. I have copied Stacey in case further clarification is needed. Rao. > -Seb > > --------------070503010102000803030903 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sebastien Roy wrote: 
On Fri, 2009-08-21 at 23:51 +0100, Ceri Davies wrote:
  
On Fri, Aug 21, 2009 at 02:43:19PM -0700, Rao Shoaib wrote:
    
Jim,

I have been told that we can ask ISC to maintain backward compatibility 
for documented interfaces. So we would like to change the classification 
of  all the documented interfaces to Committed.
      
Have ISC agreed to do this?  If not, I feel that the change is somewhat
premature.
    

The most important part isn't what ISC agrees to do, but what the
project team is willing to guarantee to consumers of the interface.  If
these are Committed interfaces, then the project team and the entity
that delivers the OS need to treat them as such.  This means that if the
upstream source changes in a way that is counter to that classification,
then something must be done to maintain backward compatibility beyond
just sucking the upstream sources unmodified.  That has been done
before...

Sun has a contract with ISC and Stacey maintains that relationship. I made changes to interface stability level after Stacey told me that Sun would have a case with ISC if documented interfaces were changed in an incompatible way. I have copied Stacey in case further clarification is needed.

Rao.

-Seb

--------------070503010102000803030903-- From carlsonj@workingcode.com Sat Aug 22 23:06:29 2009 Received: from dm-sfbay-01.sfbay.sun.com (dm-sfbay-01.SFBay.Sun.COM [129.145.155.118]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7N66TRV015056 for ; Sat, 22 Aug 2009 23:06:29 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n7N66S5Z060927 for ; Sat, 22 Aug 2009 23:06:29 -0700 (PDT) Received: from relay13i.sun.com (ip123.net129179-4.block1.us.syntegra.com [129.179.4.123]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n7N5xQ6g006574 for ; Sun, 23 Aug 2009 06:06:28 GMT Received: from mmp11es.mmp.us.syntegra.com ([160.41.208.11] [160.41.208.11]) by relay13i.sun.com with ESMTP id BT-MMP-851594 for psarc-ext@sac.sfbay.sun.com; Sun, 23 Aug 2009 06:06:28 Z Received: from relay13i.sun.com (relay13i.sun.com [129.179.4.123]) by mmp11es.mmp.us.syntegra.com with ESMTP id BT-MMP-5823202 for psarc-ext@sac.sfbay.sun.com; Sun, 23 Aug 2009 06:06:28 Z Received: from relay42i.sun.com ([192.5.209.72] [192.5.209.72]) by relay1i.sun.com with ESMTP id BT-MMP-24516461 for psarc-ext@sac.sfbay.sun.com; Sun, 23 Aug 2009 06:06:27 Z Received: from mmp41es.mmp.us.syntegra.com ([160.41.221.10] [160.41.221.10]) by relay42i.sun.com with ESMTP id BT-MMP-63375 for psarc-ext@sac.sfbay.sun.com; Sun, 23 Aug 2009 04:35:53 Z Received: from relay45i.sun.com (relay45i.sun.com [192.5.209.94]) by mmp41es.mmp.us.syntegra.com with ESMTP id BT-MMP-2866767; Sun, 23 Aug 2009 04:35:29 Z Received: from carlson.workingcode.com ([75.150.68.97] [75.150.68.97]) by relay4i.sun.com with ESMTP id BT-MMP-1746367; Sun, 23 Aug 2009 04:20:05 Z Received: from [192.168.254.182] (dhcp-182 [192.168.254.182]) (authenticated bits=0) by carlson.workingcode.com (8.14.2+Sun/8.14.3) with ESMTP id n7N4JAlj026648 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 23 Aug 2009 00:19:10 -0400 (EDT) Message-ID: <4A90C33E.1040103@workingcode.com> Date: Sun, 23 Aug 2009 00:19:10 -0400 From: James Carlson User-Agent: Thunderbird 2.0.0.21 (X11/20090323) To: Rao Shoaib CC: Sebastien Roy , psarc-ext , Ed Posnak Subject: Re: update libresolv to ISC_6.0_p1b [PSARC/2009/370 FastTrack timeout 08/25/2009] References: <1250634989.10348.153.camel@strat> <4A8B5538.80303@workingcode.com> <4A8B8FC5.5000507@sun.com> <4A8C008F.7000301@workingcode.com> <4A8F14F7.8020106@sun.com> In-Reply-To: <4A8F14F7.8020106@sun.com> X-Brightmail-Tracker: AAAAAA== X-Brightmail-Tracker: AAAAAA== X-DCC-dmv.com-Metrics: carlson 1181; Body=4 Fuz1=4 Fuz2=4 X-Antispam: No, score=0.0/5.0, scanned in 0.054sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Status: RO Content-Length: 1378 Rao Shoaib wrote: > Jim, > > I have been told that we can ask ISC to maintain backward compatibility > for documented interfaces. So we would like to change the classification > of all the documented interfaces to Committed. The following tables > lists those interfaces. > > New Committed Interfaces > |______________________________________________________________________| > | Interface | Classification | Modifier/Comments | > |______________________|_______________________|_______________________| > | | | | > | ns_sign | Committed | Documented[6] | > | ns_sign_tcp | Committed | Documented[6] | > | ns_sign_tcp_init | Committed | Documented[6] | > | ns_verify | Committed | Documented[6] | > | ns_verify_tcp | Committed | Documented[6] | > | ns_verify_tcp_init | Committed | Documented[6] | > | ns_find_tsig | Committed | Documented[6] | > | inet_cidr_ntop | Committed | Documented[5] | > | inet_cidr_pton | Committed | Documented[5] | > | inet_neta | Committed | Documented[5] | > |______________________|_______________________|_______________________| I guess I don't know what uses those particular ns_* functions, but that seems reasonable to me. -- James Carlson 42.703N 71.076W From Stacey.Marshall@Sun.COM Mon Aug 24 02:37:37 2009 Received: from dm-sfbay-01.sfbay.sun.com (dm-sfbay-01.SFBay.Sun.COM [129.145.155.118]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7O9bbqf025615 for ; Mon, 24 Aug 2009 02:37:37 -0700 (PDT) Received: from gmp-eb-inf-1.sun.com (gmp-eb-inf-1.EU.Sun.COM [192.18.6.21]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n7O9baNN056643 for ; Mon, 24 Aug 2009 02:37:37 -0700 (PDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n7O9bVqk028603 for ; Mon, 24 Aug 2009 09:37:31 GMT MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_jqn8gsPioMW1fRyMgzmNgQ)" Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KOV00M00JZ7IH00@fe-emea-09.sun.com> for psarc-ext@sac.sfbay.sun.com; Mon, 24 Aug 2009 10:37:10 +0100 (BST) Received: from [129.156.173.215] ([unknown] [129.156.173.215]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KOV00FZWK1U0280@fe-emea-09.sun.com>; Mon, 24 Aug 2009 10:37:06 +0100 (BST) Date: Mon, 24 Aug 2009 10:37:37 +0100 From: Stacey Jonathan Marshall Subject: Re: update libresolv to ISC_6.0_p1b [PSARC/2009/370 FastTrack timeout 08/25/2009] In-reply-to: <4A902259.7040100@sun.com> Sender: Stacey.Marshall@Sun.COM To: Rao Shoaib Cc: Sebastien Roy , Ceri Davies , James Carlson , Ed Posnak , psarc-ext Message-id: <4A925F61.10004@sun.com> Organization: Solaris RPE References: <1250634989.10348.153.camel@strat> <4A8B5538.80303@workingcode.com> <4A8B8FC5.5000507@sun.com> <4A8C008F.7000301@workingcode.com> <4A8F14F7.8020106@sun.com> <20090821225127.GA53064@submonkey.net> <1250951992.1497.12.camel@seb> <4A902259.7040100@sun.com> User-Agent: Thunderbird 2.0.0.21 (X11/20090323) Status: RO Content-Length: 7796 This is a multi-part message in MIME format. --Boundary_(ID_jqn8gsPioMW1fRyMgzmNgQ) Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT I've requested clarification from the ISC. See attached. Stace On 22/08/2009 17:52, Rao Shoaib wrote: > Sebastien Roy wrote: >> On Fri, 2009-08-21 at 23:51 +0100, Ceri Davies wrote: >> >>> On Fri, Aug 21, 2009 at 02:43:19PM -0700, Rao Shoaib wrote: >>> >>>> Jim, >>>> >>>> I have been told that we can ask ISC to maintain backward compatibility >>>> for documented interfaces. So we would like to change the classification >>>> of all the documented interfaces to Committed. >>>> >>> Have ISC agreed to do this? If not, I feel that the change is somewhat >>> premature. >>> >> The most important part isn't what ISC agrees to do, but what the >> project team is willing to guarantee to consumers of the interface. If >> these are Committed interfaces, then the project team and the entity >> that delivers the OS need to treat them as such. This means that if the >> upstream source changes in a way that is counter to that classification, >> then something must be done to maintain backward compatibility beyond >> just sucking the upstream sources unmodified. That has been done >> before... >> > > Sun has a contract with ISC and Stacey maintains that relationship. I > made changes to interface stability level after Stacey told me that > Sun would have a case with ISC if documented interfaces were changed > in an incompatible way. I have copied Stacey in case further > clarification is needed. > > Rao. > >> -Seb >> >> > --Boundary_(ID_jqn8gsPioMW1fRyMgzmNgQ) Content-type: message/rfc822; name="Attached Message" Return-path: Received: from fe-emea-10.sun.com ([unknown] [192.18.6.120]) by emea5-mail1.uk.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTP id <0KOV007RFJ65EC40@emea5-mail1.uk.sun.com> for sm26363@emea5-mail1.uk.Sun.COM; Mon, 24 Aug 2009 10:18:05 +0100 (BST) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KOV00I00ICRIK00@fe-emea-10.sun.com> for sm26363@emea5-mail1.uk.Sun.COM (ORCPT bind-iteam-ext@sun.com); Mon, 24 Aug 2009 10:18:05 +0100 (BST) Received: from phys-emea5-1.uk.sun.com ([unknown] [192.18.6.7]) by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTP id <0KOV004ZFJ5VA2C0@fe-emea-10.sun.com> for sm26363@emea5-mail1.uk.Sun.COM (ORCPT bind-iteam-ext@sun.com); Mon, 24 Aug 2009 10:17:55 +0100 (BST) Received: from dm-uk-02.uk.sun.com ([unknown] [129.156.101.196]) by emea5-mail1.uk.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTP id <0KOV007OAJ5VEC40@emea5-mail1.uk.sun.com> for sm26363@emea5-mail1.uk.Sun.COM (ORCPT bind-iteam-ext@sun.com); Mon, 24 Aug 2009 10:17:55 +0100 (BST) Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by dm-uk-02.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n7O9Htdd008213; Mon, 24 Aug 2009 10:17:55 +0100 (BST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n7O9HhjP008387; Mon, 24 Aug 2009 10:17:51 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KOV00K0DJ5ODE00@nwk-avmta-2.sfbay.sun.com>; Mon, 24 Aug 2009 02:17:48 -0700 (PDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KOV00EHFJ5N6160@nwk-avmta-2.sfbay.sun.com>; Mon, 24 Aug 2009 02:17:47 -0700 (PDT) Received: from relay14i.sun.com (ip124.net129179-4.block1.us.syntegra.com [129.179.4.124]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n7O9AnMf005208; Mon, 24 Aug 2009 09:17:46 +0000 (GMT) Received: from mmp14es.mmp.us.syntegra.com ([160.41.208.14] [160.41.208.14]) by relay14i.sun.com with ESMTP id BT-MMP-850801; Mon, 24 Aug 2009 09:17:45 +0000 (Z) Received: from relay15i.sun.com (relay15i.sun.com [129.179.4.125]) by mmp14es.mmp.us.syntegra.com with ESMTP id BT-MMP-18185; Mon, 24 Aug 2009 09:17:44 +0000 (Z) Received: from mx.isc.org ([204.152.184.167] [204.152.184.167]) by relay1i.sun.com with ESMTP id BT-MMP-24527168; Mon, 24 Aug 2009 09:17:28 +0000 (Z) Received: from nexus.isc.org (nexus.isc.org [IPv6:2001:4f8:1:d::13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "nexus.isc.org", Issuer "ISC CA" (verified OK)) by mx.isc.org (Postfix) with ESMTPS id 8A52411401F; Mon, 24 Aug 2009 09:17:24 +0000 (UTC envelope-from www@isc.org) Received: by nexus.isc.org (Postfix, from userid 80) id CB4D8959AC; Mon, 24 Aug 2009 09:17:22 +0000 (UTC) Date: Mon, 24 Aug 2009 09:17:22 +0000 From: Stacey Marshall via RT Subject: [ISC-Support #2842] libbind: Confirmation of committed interfaces In-reply-to: Sender: www@isc.org To: Stacey.Marshall@Sun.COM Cc: bind-iteam-ext@Sun.COM Reply-to: sun@support.isc.org Message-id: MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Precedence: bulk RT-Ticket: ISC-Support #2842 Managed-by: RT 3.8.4 (http://www.bestpractical.com/rt/) RT-Originator: stacey.marshall@sun.com X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-RT-Loop-Prevention: ISC-Support X-RT-Original-Encoding: utf-8 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mx.isc.org References: Original-recipient: rfc822;bind-iteam-ext@sun.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.2.5 Hi, The project to update libresolv in Solaris to libbind 6 is seeking clarification that the documented interfaces are committed; they will remain stable and not change in an incompatible manner. Further details of the project may be viewed here: Summary of interfaces seeking clarification: _____________________________________________________________________ | Interface | Classification | Modifier/Comments | |______________________|_______________________|_____________________| | ns_sign | Committed | Documented[6] | | ns_sign_tcp | Committed | Documented[6] | | ns_sign_tcp_init | Committed | Documented[6] | | ns_verify | Committed | Documented[6] | | ns_verify_tcp | Committed | Documented[6] | | ns_verify_tcp_init | Committed | Documented[6] | | ns_find_tsig | Committed | Documented[6] | | inet_cidr_ntop | Committed | Documented[5] | | inet_cidr_pton | Committed | Documented[5] | | inet_neta | Committed | Documented[5] | |______________________|_______________________|_____________________| [5] inet_cidr.cat3 [6] tsig.cat3 Note: man pages[5,6] provided with the case material are the ones that are shipped by ISC. Their content will be used to write Solaris man pages in standard solaris format. for example these man pages do not indicate linking with libresolv but Solaris man pages will. -- Stacey Marshall Sun Microsystems Ltd. --Boundary_(ID_jqn8gsPioMW1fRyMgzmNgQ)-- From Sebastien.Roy@Sun.COM Wed Aug 26 19:46:33 2009 Received: from dm-sfbay-02.sfbay.sun.com (dm-sfbay-02.SFBay.Sun.COM [129.146.11.31]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7R2kXJj019527 for ; Wed, 26 Aug 2009 19:46:33 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n7R2kXcs031544 for ; Wed, 26 Aug 2009 19:46:33 -0700 (PDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n7R2kXq8016373 for ; Thu, 27 Aug 2009 02:46:33 GMT MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KP000900KP57H00@mail-amer.sun.com> for psarc-ext@sac.sfbay.sun.com; Wed, 26 Aug 2009 20:46:33 -0600 (MDT) Received: from [192.168.1.3] ([unknown] [173.76.19.212]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KP0001OIL1K28D0@mail-amer.sun.com>; Wed, 26 Aug 2009 20:46:33 -0600 (MDT) Date: Wed, 26 Aug 2009 22:46:31 -0400 From: Sebastien Roy Subject: Re: update libresolv to ISC_6.0_p1b [PSARC/2009/370 FastTrack timeout 08/25/2009] In-reply-to: <1250634989.10348.153.camel@strat> Sender: Sebastien.Roy@Sun.COM To: psarc-ext Cc: Ed Posnak , "Rao.Shoaib" Message-id: <1251341191.1836.5.camel@seb> Organization: Sun Microsystems X-Mailer: Evolution 2.26.3 References: <1250634989.10348.153.camel@strat> Status: RO Content-Length: 247 On Tue, 2009-08-18 at 18:36 -0400, Sebastien Roy wrote: > I'm sponsoring this fasttrack for Ed Posnak , it > times out on 08/25/2009. This case has timed out and has the required +1 for approval. It is now approved. -Seb