From sacadmin Thu Jun 22 13:30:36 2006 Received: from eastmail2bur.East.Sun.COM (eastmail2bur.East.Sun.COM [129.148.13.40]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k5MKUatH000145 for ; Thu, 22 Jun 2006 13:30:36 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k5MKUZ0b008641; Thu, 22 Jun 2006 16:30:35 -0400 (EDT) Received: from 127.0.0.1 (localhost [127.0.0.1]) by thunk.east.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k5MKUZas016881; Thu, 22 Jun 2006 16:30:35 -0400 (EDT) Subject: 2006/409 IKE configuration of SA lifetimes From: Bill Sommerfeld To: psarc@sac.sfbay.sun.com Cc: ipsec-core@sun.com Content-Type: text/plain; charset=ISO-8859-1 Message-Id: <1151008234.13601.140.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.338 Date: Thu, 22 Jun 2006 16:30:35 -0400 Content-Transfer-Encoding: 7bit Status: RO Content-Length: 10818 I'm sponsoring this fast-track for Mark Fenwick. Timer expires 6/29/2006. Proposed release binding is "Patch", stability level is "Committed". This proposes some in.iked(1M) configuration file extensions to allow the system administrator to configure the phase2 (aka. Quick Mode) SOFT lifetimes for security asscociations created by in.iked. The use of SOFT and HARD lifetimes is fully described in RFC 2367 (PF_KEY); in short, a SOFT expiration is a warning that a security association is nearing the end of its useful lifetime; a HARD expiration is reported when it can no longer be reused. The default values, used in the absence of a configuation file entry are currently only documented in the source. it's proposed that a small extension to the ikeadm(1M) command would make discovering these easier for the system administrator. The changes proposed by this case would be implemented as part of: 5039559 IKE should use soft expires and aggressively negotiate new SAs 6430076 Default values used by in.iked are not documented Currently, in.iked configures SOFT lifetime values based on the chosen HARD lifetime and a hard coded formula. The HARD lifetime of a phase2 security association can be configured using the configuration file token p2_lifetime_secs. EG: p2_lifetime_secs This case proposes to let the soft lifetime to be independently specified with the p2_softlife_secs token. EG: p2_softlife_secs This will allow the systems administrator to specify the interval in seconds between a security association being added and the kernel sending a SOFT expire to in.iked via PF_KEY. If the systems administrator chooses not to set the SOFT lifetime, then default values will be used. The default is currently 90% of the HARD lifetime values, but subject to change. The Solaris implementation of RFC 2401 allows security association lifetimes to be specified in seconds and/or bytes protected. If both are specified, the first limit to be reached takes precedence. Currently, in.iked does not exchange or propose "byte lifetimes" unless they are proposed by a peer system (running some other key management daemon). This case proposes the following configuartion file tokens to allow the systems administrator to define the lifetime of a security association based on bytes protected: p2_lifetime_kb p2_softlife_kb The value specified is in kilobytes as defined in RFC 2409 (IKE), these values are converted to bytes before being passed to the kernel via PF_KEY (RFC 2367). To make it easier for the administrator to discover the default values used by in.iked, a proposed extension to the existing door interface used by ikeadm(1M) will access these values in the running in.iked process. The output will differentiate between hard coded defaults and values that have been overriden by a configuration file entry. Sample output from "ikeadm get defaults" : ikeadm> get defaults Global defaults. Some values can be over-ridden on a per rule basis. Token: Source: Value: Unit: Description: p1_lifetime_secs config 160 seconds phase 1 lifetime - default 60 seconds minimum phase 1 lifetime p1_nonce_len default 32 bytes phase 1 nonce length p2_lifetime_secs config 600 seconds phase 2 lifetime p2_softlife_secs config 540 seconds phase 2 soft lifetime p2_lifetime_kb config 50000K bytes phase 2 lifetime p2_softlife_kb config 45000K bytes phase 2 soft lifetime - default 60 seconds minimum phase 2 lifetime p2_nonce_len default 32 bytes phase 2 nonce length - default 3600 seconds default phase 2 lifetime - default 10 seconds minimum phase 2 soft delta p2_pfs default 0 phase 2 PFS max_certs default 1024 max certificates - default 500 IKE port number - default 4500 NAT-T port number The output of this command is for human consumption and is not an interface. Sample configuration file: # These values are defaults for my configuration # but can be overriden on a per rule basis. p1_lifetime_secs 120 p2_lifetime_secs 600 p2_softlife_secs 300 p2_lifetime_kb 500 p2_softlife_kb 400 p1_nonce_len 20 { label "test config - preshare" local_id_type IP local_addr 192.168.99.1 remote_addr 192.168.99.2 # This rule will have a default phase2 life of 600 seconds # but will soft expire after 400 seconds instead of 300. p2_softlife_secs 400 p1_xform {auth_method preshared oakley_group 1 auth_alg sha1 encr_alg des} } These are the suggested changes to ike.config(4) *** ike.config.out.save Fri Apr 28 15:57:05 2006 --- ike.config.out.1 Fri Apr 28 16:41:33 2006 *************** *** 357,366 **** --- 357,404 ---- The following IKE rule parameters can be prefigured using file-level defaults. Values specified within any given rule override these defaults, unless a rule cannot. + p2_lifetime_secs + + The proposed default lifetime, in seconds, of an IKE + phase 2 security association (SA). This value is optional + a default value will be used if omitted. + + p2_softlife_secs + + The soft lifetime of a phase 2 security association in seconds. + If this value is specified, the security association will soft + expire after p2_softlife_secs, this will cause in.iked to + renegotiate a new phase 2 security association before the + original security association expires. + + This value is optional, if omitted soft expiry will occur + after 90% of the lifetime specified by p2_lifetime_secs. The + value specified by p2_softlife_secs will be ignored if + p2_lifetime_secs is not specified. + + p2_lifetime_kb + + The lifetime of a security association can optionally be specified + in Kilo Bytes, this value with specify the default value. If lifetimes + are specified in seconds and kilobytes, the security association + will expire when either the seconds or kilobyte threshholds are + passed. + + p2_softlife_kb + + This value is the number of kilobytes that can be protected by + a security association before a soft expire occurs (see + p2_softlife_secs). + + This value is optional, if omitted soft expiry will occur + after 90% of the lifetime specified by p2_lifetime_kb. The + value specified by p2_softlife_kb will be ignored if + p2_lifetime_kb is not specified. + p2_nonce_len num The length in bytes of the phase 2 (quick mode) nonce data. This cannot be specified on a per-rule basis. These are the suggested changes to ikeadm(1M) *** ikeadm.txt.save Wed May 3 11:54:01 2006 --- ikeadm.txt Wed May 24 11:36:59 2006 *************** *** 1,8 **** - System Administration Commands ikeadm(1M) NAME --- 1,7 ---- *************** *** 10,20 **** and state SYNOPSIS ikeadm [-np] ! ikeadm [-np] get [debug | priv | stats] ikeadm [-np] set [debug | priv] [level] [file] ikeadm [-np] [get | del] [p1 | rule | preshared] [id] --- 9,19 ---- and state SYNOPSIS ikeadm [-np] ! ikeadm [-np] get [debug | priv | stats | defaults] ikeadm [-np] set [debug | priv] [level] [file] ikeadm [-np] [get | del] [p1 | rule | preshared] [id] *************** *** 116,130 **** get Lookup and display the specified object. May be used to view the current debug or ! privilege level, global statistics for the ! daemon, or a specific IKE (Phase 1) SA, pol- ! icy rule, or preshared key. The latter three ! object types require that identifying infor- ! mation be passed in; the appropriate SunOS 5.10 Last change: 30 Oct 2003 2 --- 115,129 ---- get Lookup and display the specified object. May be used to view the current debug or ! privilege level, global statistics and default ! values for the daemon, or a specific IKE ! (Phase 1) SA, policy rule, or preshared key. ! The latter three object types require that ! identifying infor mation be passed in; SunOS 5.10 Last change: 30 Oct 2003 2 *************** *** 135,146 **** System Administration Commands ikeadm(1M) ! specification for each object type is ! described below. help Print a brief summary of commands, or, when followed by a command, prints information --- 134,145 ---- System Administration Commands ikeadm(1M) ! the appropriate specification for each ! object type is described below. help Print a brief summary of commands, or, when followed by a command, prints information *************** *** 314,325 **** --- 313,336 ---- o Whether a PKCS#11 library is in use, and if applicable, the PKCS#11 library that is loaded. See Using stats to Ver- ify Hardware Accelerator. + defaults Display default values used by daemon. Some + values can be overriden in the daemon + configuration file, for these values the + token name is displayed in the output. + In cases where a configuration token has + changed the default, this will be also + be indicated in the output. + Default values may be ignored because a + peer system made a valid alternative + proposal, or they may be overriden by per + rule values, this information is not displayed. + p1 An IKE Phase 1 SA. A p1 object is identified by an IP address pair or a cookie pair; identification formats are described below. From sacadmin Thu Jun 22 13:55:00 2006 Received: from eastmail2bur.East.Sun.COM (eastmail2bur.East.Sun.COM [129.148.13.40]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k5MKt0g7001014 for ; Thu, 22 Jun 2006 13:55:00 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k5MKsx5j021528; Thu, 22 Jun 2006 16:54:59 -0400 (EDT) Received: from 127.0.0.1 (localhost [127.0.0.1]) by thunk.east.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k5MKsxLi017130; Thu, 22 Jun 2006 16:54:59 -0400 (EDT) Subject: Re: 2006/409 IKE configuration of SA lifetimes From: Bill Sommerfeld To: psarc@sac.sfbay.sun.com Cc: ipsec-core@sun.com In-Reply-To: <1151008234.13601.140.camel@thunk> References: <1151008234.13601.140.camel@thunk> Content-Type: text/plain; charset=iso-8859-1 Message-Id: <1151009698.13601.147.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.338 Date: Thu, 22 Jun 2006 16:54:59 -0400 Content-Transfer-Encoding: 7bit Status: RO Content-Length: 418 On Thu, 2006-06-22 at 16:30, Bill Sommerfeld wrote: > This proposes some in.iked(1M) configuration file extensions to allow > the > system administrator to configure the phase2 (aka. Quick Mode) SOFT > lifetimes ... As you can see, I screwed up causing my mailer to screw up the word-wrapping of the proposal. See the mail archive for a correctly word-wrapped version of the spec (i fixed it there). - Bill From sacadmin Wed Jun 28 09:16:00 2006 Received: from engmail3mpk.sfbay.Sun.COM (engmail3mpk.SFBay.Sun.COM [129.146.11.26]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k5SGG0VR027672 for ; Wed, 28 Jun 2006 09:16:00 -0700 (PDT) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by engmail3mpk.sfbay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k5SGG0CA025364; Wed, 28 Jun 2006 09:16:00 -0700 (PDT) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id k5SGHF2e021705; Wed, 28 Jun 2006 09:17:15 -0700 (PDT) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id k5SGHFtS021704; Wed, 28 Jun 2006 09:17:15 -0700 (PDT) Date: Wed, 28 Jun 2006 09:17:15 -0700 (PDT) From: Gary Winiger Message-Id: <200606281617.k5SGHFtS021704@marduk.eng.sun.com> To: psarc@sac.sfbay.sun.com, sommerfeld@sun.com Cc: ipsec-core@sun.com Subject: Re: 2006/409 IKE configuration of SA lifetimes Status: RO Content-Length: 284 > I'm sponsoring this fast-track for Mark Fenwick. Timer expires > 6/29/2006. > > Proposed release binding is "Patch", stability level is "Committed". Nit: What is the stability of the output of get? Perhaps Not an Interface. Please update the man page to be clear. Gary.. From sacadmin Wed Jun 28 12:13:46 2006 Received: from eastmail1bur.East.Sun.COM (eastmail1bur.East.Sun.COM [129.148.9.49]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k5SJDkRi009047 for ; Wed, 28 Jun 2006 12:13:46 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k5SJDi8d014636; Wed, 28 Jun 2006 15:13:44 -0400 (EDT) Received: from 127.0.0.1 (localhost [127.0.0.1]) by thunk.east.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k5SJDiaG008516; Wed, 28 Jun 2006 15:13:44 -0400 (EDT) Subject: Re: 2006/409 IKE configuration of SA lifetimes From: Bill Sommerfeld To: Gary Winiger Cc: psarc@sac.sfbay.sun.com, ipsec-core@sun.com In-Reply-To: <200606281617.k5SGHFtS021704@marduk.eng.sun.com> References: <200606281617.k5SGHFtS021704@marduk.eng.sun.com> Content-Type: text/plain Message-Id: <1151522023.7274.21.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.338 Date: Wed, 28 Jun 2006 15:13:43 -0400 Content-Transfer-Encoding: 7bit Status: RO Content-Length: 419 On Wed, 2006-06-28 at 12:17, Gary Winiger wrote: > > Proposed release binding is "Patch", stability level is "Committed". > > Nit: What is the stability of the output of get? > Perhaps Not an Interface. > Please update the man page to be clear. The non-manpage part of the case description specifies that the output is not-an-interface. The actual manpage will be updated to say that as well. - Bill From sacadmin Thu Jun 29 04:08:08 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.58.37]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k5TB88Ek002906 for ; Thu, 29 Jun 2006 04:08:08 -0700 (PDT) Received: from [129.150.12.95] (vpn-129-150-12-95.SFBay.Sun.COM [129.150.12.95]) by jurassic.eng.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k5TB86qo410061; Thu, 29 Jun 2006 04:08:07 -0700 (PDT) Message-ID: <44A3B496.3080103@sun.com> Date: Thu, 29 Jun 2006 01:08:06 -1000 From: Joseph Kowalski User-Agent: Mail/News 1.5.0.2 (X11/20060515) MIME-Version: 1.0 To: Gary Winiger CC: psarc@sac.sfbay.sun.com, sommerfeld@sun.com, ipsec-core@sun.com Subject: Re: 2006/409 IKE configuration of SA lifetimes References: <200606281617.k5SGHFtS021704@marduk.eng.sun.com> In-Reply-To: <200606281617.k5SGHFtS021704@marduk.eng.sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 951 Gary Winiger wrote: >> I'm sponsoring this fast-track for Mark Fenwick. Timer expires >> 6/29/2006. >> >> Proposed release binding is "Patch", stability level is "Committed". >> > > Nit: What is the stability of the output of get? > Perhaps Not an Interface. > Please update the man page to be clear. > > Gary.. > I've not paid *any* attention to this particular case (sorry), but I think I want to make sure this request is in line with the intent of "Not an Interface". Is it likely that the consumer will assume it is some form of interface? If so, then the case materials (including the prototype man page (probably) should include this label. Otherwise, it isn't interesting. What I'm trying to make sure of is that "Not an Interface" is used in the relatively few instances where confusion is likely. If the line Text Output Not an Interface appears in most manpages, something has gone wrong. - jek3 From sacadmin Thu Jun 29 08:04:24 2006 Received: from engmail3mpk.sfbay.Sun.COM (engmail3mpk.SFBay.Sun.COM [129.146.11.26]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k5TF4OLq008913 for ; Thu, 29 Jun 2006 08:04:24 -0700 (PDT) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by engmail3mpk.sfbay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k5TF4NNo014274; Thu, 29 Jun 2006 08:04:23 -0700 (PDT) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id k5TF5e1q023700; Thu, 29 Jun 2006 08:05:40 -0700 (PDT) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id k5TF5e7e023699; Thu, 29 Jun 2006 08:05:40 -0700 (PDT) Date: Thu, 29 Jun 2006 08:05:40 -0700 (PDT) From: Gary Winiger Message-Id: <200606291505.k5TF5e7e023699@marduk.eng.sun.com> To: gww@eng.sun.com, jek3@sun.com Subject: Re: 2006/409 IKE configuration of SA lifetimes Cc: psarc@sac.sfbay.sun.com, sommerfeld@sun.com, ipsec-core@sun.com X-Sun-Charset: US-ASCII Status: RO Content-Length: 757 > What I'm trying to make sure of is that "Not an Interface" is used in the > relatively few instances where confusion is likely. If the line > > Text Output Not an Interface > > appears in most manpages, something has gone wrong. Indeed that was my request. I'd missed seeing the line in the case materials that said output is for human consumption only. That was pointed out as being present by the project team. I requested when the man page was updated that it be explicit in the attributes. Further out of band discussions with the project team confirmed such a statement would be added to the man page ATTRIBUTES section. The project team does not supply a ``stable'' form of output for the get or list commands. Gary.. From sacadmin Thu Jun 29 08:34:03 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.228.50]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k5TFY32A009428 for ; Thu, 29 Jun 2006 08:34:03 -0700 (PDT) Received: from [129.150.12.95] (vpn-129-150-12-95.SFBay.Sun.COM [129.150.12.95]) by jurassic.eng.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k5TFY1BL466547; Thu, 29 Jun 2006 08:34:02 -0700 (PDT) Message-ID: <44A3F2E9.7080503@sun.com> Date: Thu, 29 Jun 2006 05:34:01 -1000 From: Joseph Kowalski User-Agent: Mail/News 1.5.0.2 (X11/20060515) MIME-Version: 1.0 To: Gary Winiger CC: psarc@sac.sfbay.sun.com, sommerfeld@sun.com, ipsec-core@sun.com Subject: Re: 2006/409 IKE configuration of SA lifetimes References: <200606291505.k5TF5e7e023699@marduk.eng.sun.com> In-Reply-To: <200606291505.k5TF5e7e023699@marduk.eng.sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 1563 Gary Winiger wrote: >> What I'm trying to make sure of is that "Not an Interface" is used in the >> relatively few instances where confusion is likely. If the line >> >> Text Output Not an Interface >> >> appears in most manpages, something has gone wrong. >> > > Indeed that was my request. I'd missed seeing the line in > the case materials that said output is for human consumption > only. That was pointed out as being present by the project > team. I requested when the man page was updated that it > be explicit in the attributes. Further out of band discussions > with the project team confirmed such a statement would be > added to the man page ATTRIBUTES section. The project team > does not supply a ``stable'' form of output for the get > or list commands. > > Gary. > Hummm,... My belief was that the attributes(5) man page (and whatever) would say something like: Unless noted otherwise, textual output from utilities should not be considered to be appropriate for programatic consumption. (OK, those words suck. That's why I'm not a tech writer, but you get the idea). If we start labeling man pages with "Not an Interface", I fear that folk will start assuming that the lack of a warning means its "OK". Putting "Not an Interface" in any case materials never hurts. I don't always think its necessary, but it doesn't hurt. I just don't think we start forcing this on to every man page. I seem to recall this limitted usage led to the "is it really useful" discussion many, many moons ago. - jek3 From sacadmin Thu Jun 29 15:11:06 2006 Received: from eastmail4bur.east.Sun.COM (eastmail4bur.East.Sun.COM [129.148.13.1]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k5TMB6QT027323 for ; Thu, 29 Jun 2006 15:11:06 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail4bur.east.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k5TMB5x3007263; Thu, 29 Jun 2006 18:11:05 -0400 (EDT) Received: from 127.0.0.1 (localhost [127.0.0.1]) by thunk.east.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k5TMB5Cb016375; Thu, 29 Jun 2006 18:11:05 -0400 (EDT) Subject: Re: 2006/409 IKE configuration of SA lifetimes From: Bill Sommerfeld To: psarc@sac.sfbay.sun.com Cc: ipsec-core@sun.com In-Reply-To: <1151008234.13601.140.camel@thunk> References: <1151008234.13601.140.camel@thunk> Content-Type: text/plain Message-Id: <1151619064.13951.15.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.338 Date: Thu, 29 Jun 2006 18:11:05 -0400 Content-Transfer-Encoding: 7bit Status: RO Content-Length: 737 I was informed when I dialed in late that this case was approved during ARC business of yesterday's PSARC meeting; I've marked it as such. Since the meeting there was discussion regarding best practices with respect to what documentation should say regarding the general principle that output intended for human consumption should not be regarded as a programmatic interface. It does not appear to me that this discussion affects the approval status of the case but is really more of an implementation detail.. In this specific case, there is currently no other interface to display the values currently in effect so I see a modest risk that the output of the "get defaults" command will be mistaken for an interface. - Bill From sacadmin Thu Jun 29 15:21:00 2006 Received: from engmail3mpk.sfbay.Sun.COM (engmail3mpk.SFBay.Sun.COM [129.146.11.26]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k5TML0K6027370 for ; Thu, 29 Jun 2006 15:21:00 -0700 (PDT) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by engmail3mpk.sfbay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k5TMKx37018378; Thu, 29 Jun 2006 15:20:59 -0700 (PDT) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id k5TMMGGb024728; Thu, 29 Jun 2006 15:22:16 -0700 (PDT) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id k5TMMGsh024727; Thu, 29 Jun 2006 15:22:16 -0700 (PDT) Date: Thu, 29 Jun 2006 15:22:16 -0700 (PDT) From: Gary Winiger Message-Id: <200606292222.k5TMMGsh024727@marduk.eng.sun.com> To: psarc@sac.sfbay.sun.com, sommerfeld@sun.com Subject: Re: 2006/409 IKE configuration of SA lifetimes Cc: ipsec-core@sun.com X-Sun-Charset: US-ASCII Status: RO Content-Length: 612 > Since the meeting there was discussion regarding best practices with > respect to what documentation should say regarding the general principle > that output intended for human consumption should not be regarded as a > programmatic interface. It does not appear to me that this discussion > affects the approval status of the case but is really more of an > implementation detail.. I raised the issue and am happy with the answer of either include in ATTRIBUTES as other man pages have, or ensure that attributes(5) is clear within the context that the human readable output is not an interface. Gary.. From sacadmin Fri Jun 30 22:22:11 2006 Received: from engmail3mpk.sfbay.Sun.COM (engmail3mpk.SFBay.Sun.COM [129.146.11.26]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k615MBCR005806 for ; Fri, 30 Jun 2006 22:22:11 -0700 (PDT) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by engmail3mpk.sfbay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k615MB0n022496; Fri, 30 Jun 2006 22:22:11 -0700 (PDT) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id k615NUYY028095; Fri, 30 Jun 2006 22:23:30 -0700 (PDT) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id k615NUQZ028094; Fri, 30 Jun 2006 22:23:30 -0700 (PDT) Date: Fri, 30 Jun 2006 22:23:30 -0700 (PDT) From: Gary Winiger Message-Id: <200607010523.k615NUQZ028094@marduk.eng.sun.com> To: gww@eng.sun.com, jek3@sun.com Subject: Re: 2006/409 IKE configuration of SA lifetimes Cc: psarc@sac.sfbay.sun.com, sommerfeld@sun.com, ipsec-core@sun.com X-Sun-Charset: US-ASCII Status: RO Content-Length: 1046 > My belief was that the attributes(5) man page (and whatever) would say > something like: > > Unless noted otherwise, textual output from utilities should not be > considered to be appropriate for programatic consumption. > > (OK, those words suck. That's why I'm not a tech writer, but you > get the idea). Well, I think this is a perfect place to use Not an Interface rather than not be considered to be .... That of course presumes an adequate definition of NaI in attributes(5). > If we start labeling man pages with "Not an Interface", I fear that > folk will start assuming that the lack of a warning means its "OK". I get your point. attributes(5) doesn't have "your" words yet. In the past we have done some man pages explicitly, I guess I missed the required change being made to attributes(5) so individual man pages wouldn't need changing. IMO that also needs to be in the WHAT'S NEW. I.e. the change in interface taxonomy definitions and the update to attributes(5). BTW will that start in S10u3? Gary.. From sacadmin Tue Jul 11 10:59:32 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.58.166]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k6BHxWFY017255 for ; Tue, 11 Jul 2006 10:59:32 -0700 (PDT) Received: from hawaiian-sun (vpn-129-150-12-95.SFBay.Sun.COM [129.150.12.95]) by jurassic.eng.sun.com (8.13.6+Sun/8.13.6) with SMTP id k6BHxRs7283520; Tue, 11 Jul 2006 10:59:31 -0700 (PDT) Message-Id: <200607111759.k6BHxRs7283520@jurassic.eng.sun.com> Date: Tue, 11 Jul 2006 07:58:10 -1000 (HST) From: Joseph Kowalski Reply-To: Joseph Kowalski Subject: Re: 2006/409 IKE configuration of SA lifetimes To: psarc@sac.sfbay.sun.com, sommerfeld@sun.com Cc: ipsec-core@sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 4Fu3cNzW8kf/C4qGRaqbsA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_20 SunOS 5.11 i86pc i386 Status: RO Content-Length: 528 > From: Bill Sommerfeld ... > In this specific case, there is currently no other interface to display > the values currently in effect so I see a modest risk that the output of > the "get defaults" command will be mistaken for an interface. Hummm,... interesting criteria for explicitly including "Not an Interface" on the man page - displays something not otherwise obtainable. We should keep this in mind for future discussion and for the actual text to be included on the attributes(5) page. - jek3 From sacadmin Tue Jul 11 11:24:19 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.68.36]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k6BIOJJC017681 for ; Tue, 11 Jul 2006 11:24:19 -0700 (PDT) Received: from hawaiian-sun (vpn-129-150-12-95.SFBay.Sun.COM [129.150.12.95]) by jurassic.eng.sun.com (8.13.6+Sun/8.13.6) with SMTP id k6BIODsr294172; Tue, 11 Jul 2006 11:24:18 -0700 (PDT) Message-Id: <200607111824.k6BIODsr294172@jurassic.eng.sun.com> Date: Tue, 11 Jul 2006 08:22:56 -1000 (HST) From: Joseph Kowalski Reply-To: Joseph Kowalski Subject: Re: 2006/409 IKE configuration of SA lifetimes To: gww@eng.sun.com, jek3@sun.com Cc: psarc@sac.sfbay.sun.com, sommerfeld@sun.com, ipsec-core@sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: Hb8uuOSAEYgFnz2D1BcfCw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_20 SunOS 5.11 i86pc i386 Status: RO Content-Length: 365 > From: Gary Winiger ... > BTW will that start in S10u3? Hummm,... I'd been working on the assumption that the new taxonomy would be publically exposed in Nevada/Solaris Express. Having cases going through which target S10 is an interesting complication I don't think was fully considered. We need to talk to tech pubs about this. - jek3