From tkeiser@sinenomine.net Mon Aug 1 00:53:40 2011 From: tkeiser@sinenomine.net (Tom Keiser) Date: Sun, 31 Jul 2011 19:53:40 -0400 Subject: [AFS3-std] Re: XDR extensible union type In-Reply-To: <5D0108C15137EC449A517DD8454DE71503041C69F4@34093-MBX-C15.mex07a.mlsrvr.com> References: <5D0108C15137EC449A517DD8454DE71503041C69F4@34093-MBX-C15.mex07a.mlsrvr.com> Message-ID: --0015174483e85c0ec004a9663966 Content-Type: text/plain; charset=ISO-8859-1 I pushed draft-keiser-afs3-xdr-union-03 (incorporating Derrick's grammatical corrections) to the IETF last week. Comments are hereby solicited. http://tools.ietf.org/html/draft-keiser-afs3-xdr-union-03 Cheers, -Tom On Jul 20, 2011 8:46 PM, "Tom Keiser" wrote: > Hi Derrick, > > Thanks very much for the review; I'll incorporate those edits. > > I'd like to publish -03 on Tuesday. If any interested party can find time to send comments by Monday, it would be greatly appreciated. > > Cheers, > > -Tom > > Sent from my phone; please excuse any typographic or grammatical errors. > > -----Original Message----- > From: Derrick Brashear [shadow@gmail.com] > Received: Wednesday, 20 Jul 2011, 9:33am > To: Tom Keiser [tkeiser@sinenomine.net] > Subject: Re: [AFS3-std] Re: XDR extensible union type > > i lie > > "1. Lookup the discriminant" > > I believe that should be, as an operation, "look up" > > > On Wed, Jul 20, 2011 at 9:31 AM, Derrick Brashear wrote: >> 6. AFS Assign Numbers Registrar Considerations >> >> "Assigned" >> >> the actual content is fine and i see no issues. >> >> On Tue, Jul 19, 2011 at 6:02 PM, Tom Keiser wrote: >>> On Jun 20, 2011 2:41 PM, "Tom Keiser" wrote: >>>> Hi all, >>>> >>>> I pushed a new revision of draft-keiser-afs3-xdr-union: >>>> >>>> http://tools.ietf.org/html/draft-keiser-afs3-xdr-union-02 >>>> >>>> This revision incorporates the following two changes: >>>> >>>> * modify section on error handling (3.4.1) to make length mismatches a >>>> fatal error >>>> * add a "use case" section (1.1) to discuss trade-offs associated with >>>> using this type >>>> >>>> Any comments are welcome. >>>> >>>> -Tom >>> >>> This is a second call for review of draft-keiser-afs3-xdr-union-02; all >>> comments are welcome. >>> >>> Cheers, >>> >>> -Tom >> >> >> >> -- >> Derrick >> > > > > -- > Derrick --0015174483e85c0ec004a9663966 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

I pushed draft-keiser-afs3-xdr-union-03 (incorporating Derrick's gra= mmatical corrections) to the IETF last week.=A0 Comments are hereby solicit= ed.

ht= tp://tools.ietf.org/html/draft-keiser-afs3-xdr-union-03

Cheers,

-Tom

On Jul 20, 2011 8:46 PM, "Tom Keiser" = <tkeiser@sinenomine.net>= ; wrote:
> Hi Derrick,
>
> Thanks v= ery much for the review; I'll incorporate those edits.
>
> I'd like to publish -03 on Tuesday. If any interested par= ty can find time to send comments by Monday, it would be greatly appreciate= d.
>
> Cheers,
>
> -Tom
>
> Sent fro= m my phone; please excuse any typographic or grammatical errors.
>
> -----Original Message-----
> From: Derrick Brashear [shadow@gmail.com]
> Received: W= ednesday, 20 Jul 2011, 9:33am
> To: Tom Keiser [tkeiser@sinenomine.net]
> Subject: Re: [AFS3-std] Re: XDR extensible union type
>
>= i lie
>
> "1. Lookup the discriminant"
> > I believe that should be, as an operation, "look up"
>
>
> On Wed, Jul 20, 2011 at 9:31 AM, Derrick Brashear &l= t;shadow@gmail.com> wrote:
&g= t;> 6. AFS Assign Numbers Registrar Considerations
>>
>&= gt; "Assigned"
>>
>> the actual content is fine and i see no issues.
>= ;>
>> On Tue, Jul 19, 2011 at 6:02 PM, Tom Keiser <tkeiser@sinenomine.net> wrote: >>> On Jun 20, 2011 2:41 PM, "Tom Keiser" <tkeiser@sinenomine.net> wrote:
&g= t;>>> Hi all,
>>>>
>>>> I pushed a n= ew revision of draft-keiser-afs3-xdr-union:
>>>>
>>>> http://tools.ietf.org/html/draft-keiser-afs= 3-xdr-union-02
>>>>
>>>> This revision in= corporates the following two changes:
>>>>
>>>> * modify section on error handling (3.= 4.1) to make length mismatches a
>>>> fatal error
>>= ;>> * add a "use case" section (1.1) to discuss trade-offs = associated with
>>>> using this type
>>>>
>>>> An= y comments are welcome.
>>>>
>>>> -Tom
>= ;>>
>>> This is a second call for review of draft-keiser= -afs3-xdr-union-02; all
>>> comments are welcome.
>>>
>>> Cheers,<= br>>>>
>>> -Tom
>>
>>
>>>> --
>> Derrick
>>
>
>
>
> --
> Derrick
--0015174483e85c0ec004a9663966-- From simon@sxw.org.uk Mon Aug 1 18:07:35 2011 From: simon@sxw.org.uk (Simon Wilkinson) Date: Mon, 1 Aug 2011 18:07:35 +0100 Subject: [AFS3-std] Re: A call for consensus on draft-deason-afs3-type-time-02 In-Reply-To: <87fwlotw4u.fsf@windlord.stanford.edu> References: <20110728135500.76B9ED@grand.central.org> <4E31776B.1040007@odu.edu> <87ei19yma5.fsf@windlord.stanford.edu> <20110729161932.18bc0ced.adeason@sinenomine.net> <87fwlotw4u.fsf@windlord.stanford.edu> Message-ID: Given how much of what we want to do depends on defining a new time type, it= would be good to keep up the momentum with this draft. Would those with problems with the current draft be prepared to suggest new w= ording for: a) the epoch value b) the granularity that we could use as a basis for further discussion? It would also be wonder= ful if everyone with an interest in this topic could participate in that dis= cussion, rather than waiting for another last call to raise objections. Thanks, Simon= From rra@stanford.edu Mon Aug 1 18:13:57 2011 From: rra@stanford.edu (Russ Allbery) Date: Mon, 01 Aug 2011 10:13:57 -0700 Subject: [AFS3-std] Re: A call for consensus on draft-deason-afs3-type-time-02 In-Reply-To: (Simon Wilkinson's message of "Mon, 1 Aug 2011 18:07:35 +0100") References: <20110728135500.76B9ED@grand.central.org> <4E31776B.1040007@odu.edu> <87ei19yma5.fsf@windlord.stanford.edu> <20110729161932.18bc0ced.adeason@sinenomine.net> <87fwlotw4u.fsf@windlord.stanford.edu> Message-ID: <87wrex836y.fsf@windlord.stanford.edu> Simon Wilkinson writes: > Would those with problems with the current draft be prepared to suggest > new wording for: > a) the epoch value > b) the granularity > that we could use as a basis for further discussion? It would also be > wonderful if everyone with an interest in this topic could participate > in that discussion, rather than waiting for another last call to raise > objections. As nice as it would be to be able to represent old timestamps in the file system, we've never been able to before (at least consistently), and I think the simplicity benefits for compatibility with current code bases of sticking with the POSIX epoch are substantial. I don't have an opinion on the granularity. For me, the benefits of matching NFS and the POSIX timestamp granularity is fairly evenly balanced against the drawbacks of increasing the size of all of our protocol packets. -- Russ Allbery (rra@stanford.edu) From matt@linuxbox.com Mon Aug 1 18:21:47 2011 From: matt@linuxbox.com (Matt W. Benjamin) Date: Mon, 1 Aug 2011 13:21:47 -0400 (EDT) Subject: [AFS3-std] Re: A call for consensus on draft-deason-afs3-type-time-02 In-Reply-To: <87wrex836y.fsf@windlord.stanford.edu> Message-ID: <159746358.62.1312219307195.JavaMail.root@thunderbeast.private.linuxbox.com> Hi, a) with Russ b) Intuitively I would have voted and would vote for the more NFS, POSIX flavor of timestamp granularity. In prior discussion, that was not the consensus. Matt ----- "Russ Allbery" wrote: > Simon Wilkinson writes: > > > Would those with problems with the current draft be prepared to > suggest > > new wording for: > > > a) the epoch value > > b) the granularity > > As nice as it would be to be able to represent old timestamps in the > file > system, we've never been able to before (at least consistently), and > I > think the simplicity benefits for compatibility with current code > bases of > sticking with the POSIX epoch are substantial. > > I don't have an opinion on the granularity. For me, the benefits of > matching NFS and the POSIX timestamp granularity is fairly evenly > balanced > against the drawbacks of increasing the size of all of our protocol > packets. > -- Matt Benjamin The Linux Box 206 South Fifth Ave. Suite 150 Ann Arbor, MI 48104 http://linuxbox.com tel. 734-761-4689 fax. 734-769-8938 cel. 734-216-5309 From adeason@sinenomine.net Mon Aug 1 18:28:10 2011 From: adeason@sinenomine.net (Andrew Deason) Date: Mon, 1 Aug 2011 12:28:10 -0500 Subject: [AFS3-std] Re: A call for consensus on draft-deason-afs3-type-time-02 References: <20110728135500.76B9ED@grand.central.org> <4E31776B.1040007@odu.edu> <87ei19yma5.fsf@windlord.stanford.edu> <20110729161932.18bc0ced.adeason@sinenomine.net> <87fwlotw4u.fsf@windlord.stanford.edu> Message-ID: <20110801122810.81b1889c.adeason@sinenomine.net> On Mon, 1 Aug 2011 18:07:35 +0100 Simon Wilkinson wrote: > Given how much of what we want to do depends on defining a new time > type, it would be good to keep up the momentum with this draft. > > Would those with problems with the current draft be prepared to > suggest new wording for: > > a) the epoch value I don't think I've heard any significant arguments for keeping the epoch as it exists in the current draft. And since there are issues with the current epoch value that Russ has detailed, it makes sense to me to change it to the posix epoch. I was going to change it unless I heard someone object; I'll propose some new text soon based on Russ' suggestions unless someone else wants to. > b) the granularity This one I still have no idea on. I see reasons for both sides. > that we could use as a basis for further discussion? It would also be > wonderful if everyone with an interest in this topic could participate > in that discussion, rather than waiting for another last call to raise > objections. Most people involved have a lot of deadlines to work with and balance. Right now, the only "deadline" we are given for standards discussion is the last call. If you want to ensure discussion before that point, give another deadline. -- Andrew Deason adeason@sinenomine.net From shadow@gmail.com Mon Aug 1 18:32:46 2011 From: shadow@gmail.com (Derrick Brashear) Date: Mon, 1 Aug 2011 13:32:46 -0400 Subject: [AFS3-std] Re: A call for consensus on draft-deason-afs3-type-time-02 In-Reply-To: <20110801122810.81b1889c.adeason@sinenomine.net> References: <20110728135500.76B9ED@grand.central.org> <4E31776B.1040007@odu.edu> <87ei19yma5.fsf@windlord.stanford.edu> <20110729161932.18bc0ced.adeason@sinenomine.net> <87fwlotw4u.fsf@windlord.stanford.edu> <20110801122810.81b1889c.adeason@sinenomine.net> Message-ID: On Mon, Aug 1, 2011 at 1:28 PM, Andrew Deason wrote: >> b) the granularity > > This one I still have no idea on. I see reasons for both sides. So is there a reason an extended union with the various stamp granularities would be a nonstarter? In particular I'd suggest the draft strongly discourage sending a larger timestamp than actual information supports (e.g. don't use bits to send precision you don't have, rather than trailing-zero-padding a larger than needed number) -- Derrick From jaltman@secure-endpoints.com Mon Aug 1 18:39:35 2011 From: jaltman@secure-endpoints.com (Jeffrey Altman) Date: Mon, 01 Aug 2011 13:39:35 -0400 Subject: [AFS3-std] Re: A call for consensus on draft-deason-afs3-type-time-02 In-Reply-To: <87wrex836y.fsf@windlord.stanford.edu> References: <20110728135500.76B9ED@grand.central.org> <4E31776B.1040007@odu.edu> <87ei19yma5.fsf@windlord.stanford.edu> <20110729161932.18bc0ced.adeason@sinenomine.net> <87fwlotw4u.fsf@windlord.stanford.edu> <87wrex836y.fsf@windlord.stanford.edu> Message-ID: <4E36E4D7.9010308@secure-endpoints.com> This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig4A27C580FE23C3E7E55C905E Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 8/1/2011 1:13 PM, Russ Allbery wrote: > As nice as it would be to be able to represent old timestamps in the fi= le > system, we've never been able to before (at least consistently), and I > think the simplicity benefits for compatibility with current code bases= of > sticking with the POSIX epoch are substantial. > > I don't have an opinion on the granularity. For me, the benefits of > matching NFS and the POSIX timestamp granularity is fairly evenly balan= ced > against the drawbacks of increasing the size of all of our protocol > packets. I have a strong desire to ensure that everything that can be represented in an NTFS file system can be represented in AFS. I don't care if the epoch is the same or if the granularity is better than 100ns or not. I am concerned about the size of status structures given how frequently they are sent and because the size of the status structure determines how many FIDs can be specified in a single Bulk Status request. It would be nice if we could have some form of compressed time representation that only sent the required number of bits necessary to represent the required granularity. Jeffrey Altman --------------enig4A27C580FE23C3E7E55C905E Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iQEcBAEBAgAGBQJONuTdAAoJENxm1CNJffh4/1EH/2edEyuNmABtPOma63yPvItC dlmgGYHO5YnJyW7dsoPyE4+wtorPCPFpVIriwIyke7eXhBjDHYod0sE+PjMa00US elGszsC+O8YFReJQkvCUo6K82sTNmjIDI95tFtTWPuPM4NDniN7HW2IhjqbIZOX1 pArwMylZD2BUk+GjPbpElgWqQoFhB96pHgmS4UK94brY9wGfjo/geMWgN/kLm5OP pGtiAhj01mDrr5qKYe8l0fQm9EVd2BTB2TI7flshB5foFFx+86LadxQdyhUciDdg W6NHvqbEbDPoHvOqsrHg4bvxYQnsXBkDGsnC2goeZ3B1pMKt466GHoUbBtEAXXU= =EWEN -----END PGP SIGNATURE----- --------------enig4A27C580FE23C3E7E55C905E-- From rra@stanford.edu Mon Aug 1 18:50:51 2011 From: rra@stanford.edu (Russ Allbery) Date: Mon, 01 Aug 2011 10:50:51 -0700 Subject: [AFS3-std] Re: A call for consensus on draft-deason-afs3-type-time-02 In-Reply-To: <4E36E4D7.9010308@secure-endpoints.com> (Jeffrey Altman's message of "Mon, 01 Aug 2011 13:39:35 -0400") References: <20110728135500.76B9ED@grand.central.org> <4E31776B.1040007@odu.edu> <87ei19yma5.fsf@windlord.stanford.edu> <20110729161932.18bc0ced.adeason@sinenomine.net> <87fwlotw4u.fsf@windlord.stanford.edu> <87wrex836y.fsf@windlord.stanford.edu> <4E36E4D7.9010308@secure-endpoints.com> Message-ID: <87fwll81hg.fsf@windlord.stanford.edu> Jeffrey Altman writes: > I have a strong desire to ensure that everything that can be represented > in an NTFS file system can be represented in AFS. Does that include timestamps prior to 1970, just to check? -- Russ Allbery (rra@stanford.edu) From adeason@sinenomine.net Mon Aug 1 18:53:44 2011 From: adeason@sinenomine.net (Andrew Deason) Date: Mon, 1 Aug 2011 12:53:44 -0500 Subject: [AFS3-std] Re: A call for consensus on draft-deason-afs3-type-time-02 References: <20110728135500.76B9ED@grand.central.org> <4E31776B.1040007@odu.edu> <87ei19yma5.fsf@windlord.stanford.edu> <20110729161932.18bc0ced.adeason@sinenomine.net> <87fwlotw4u.fsf@windlord.stanford.edu> <20110801122810.81b1889c.adeason@sinenomine.net> Message-ID: <20110801125344.e9e45873.adeason@sinenomine.net> On Mon, 1 Aug 2011 13:32:46 -0400 Derrick Brashear wrote: > On Mon, Aug 1, 2011 at 1:28 PM, Andrew Deason wrote: > > >> b) the granularity > > > > This one I still have no idea on. I see reasons for both sides. > > So is there a reason an extended union with the various stamp > granularities would be a nonstarter? In particular I'd suggest the > draft strongly discourage > sending a larger timestamp than actual information supports (e.g. > don't use bits to send precision you don't have, rather than > trailing-zero-padding a > larger than needed number) Well, the objection to just having 64-bit seconds and 32-bit nanoseconds is "space", and a union tag is an extra 32 bits... If we had a "100 NS granularity" tag, then we'd have 100-ns granularity in 96 bits, whereas now we could have 1-ns granularity in 96 bits. Unless there's some other scheme you're thinking of that somehow makes this more efficient? I had some kind of variable-length scheme that encoded the granularity in the 'unused' bits of the value for coarser granularities, but I'm pretty sure that only saved space for the *TimeRes types, and doesn't really help for 'plain' times. -- Andrew Deason adeason@sinenomine.net From jaltman@secure-endpoints.com Mon Aug 1 19:01:25 2011 From: jaltman@secure-endpoints.com (Jeffrey Altman) Date: Mon, 01 Aug 2011 14:01:25 -0400 Subject: [AFS3-std] Re: A call for consensus on draft-deason-afs3-type-time-02 In-Reply-To: <87fwll81hg.fsf@windlord.stanford.edu> References: <20110728135500.76B9ED@grand.central.org> <4E31776B.1040007@odu.edu> <87ei19yma5.fsf@windlord.stanford.edu> <20110729161932.18bc0ced.adeason@sinenomine.net> <87fwlotw4u.fsf@windlord.stanford.edu> <87wrex836y.fsf@windlord.stanford.edu> <4E36E4D7.9010308@secure-endpoints.com> <87fwll81hg.fsf@windlord.stanford.edu> Message-ID: <4E36E9F5.9000502@secure-endpoints.com> This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig23F50A5B2A28DAF581F3533F Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 8/1/2011 1:50 PM, Russ Allbery wrote: > Jeffrey Altman writes: >=20 >> I have a strong desire to ensure that everything that can be represent= ed >> in an NTFS file system can be represented in AFS. >=20 > Does that include timestamps prior to 1970, just to check? >=20 Yes. --------------enig23F50A5B2A28DAF581F3533F Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iQEcBAEBAgAGBQJONun2AAoJENxm1CNJffh4mrIIAIEPpQF6ZniJKtOR3Go0RhOo UJihNKxv52kCD9Jsulu+C19n5L0QkqfFqXUSJNtOqU0a7M0rypzhiyOmpdKiboiB st2NhCi50BPkbVq68+GbhzHIZLNEs3aMnV8Xhhl76e9s+rmlXy7G/bY1pMxIWYAn zY58jFCcgeeTHf06qcGsop1VwyQX4Vy/POnbs5+YybtOxTGIvi/awa2YFaqLZeyz pUZe8TgpYR3XODPoc6ykc/SFoD4c+PpToHEXQFHZVWbpDpMIU9M4WmbZESRGObxX 5bqOusZgx7THzk5r5nTc8BWWmp5tnPvALz+MOlHTRvFje99rwQz/Cl+luWDY/ak= =Tflf -----END PGP SIGNATURE----- --------------enig23F50A5B2A28DAF581F3533F-- From rra@stanford.edu Mon Aug 1 19:13:50 2011 From: rra@stanford.edu (Russ Allbery) Date: Mon, 01 Aug 2011 11:13:50 -0700 Subject: [AFS3-std] Re: A call for consensus on draft-deason-afs3-type-time-02 In-Reply-To: <4E36E9F5.9000502@secure-endpoints.com> (Jeffrey Altman's message of "Mon, 01 Aug 2011 14:01:25 -0400") References: <20110728135500.76B9ED@grand.central.org> <4E31776B.1040007@odu.edu> <87ei19yma5.fsf@windlord.stanford.edu> <20110729161932.18bc0ced.adeason@sinenomine.net> <87fwlotw4u.fsf@windlord.stanford.edu> <87wrex836y.fsf@windlord.stanford.edu> <4E36E4D7.9010308@secure-endpoints.com> <87fwll81hg.fsf@windlord.stanford.edu> <4E36E9F5.9000502@secure-endpoints.com> Message-ID: <871ux580f5.fsf@windlord.stanford.edu> Jeffrey Altman writes: > On 8/1/2011 1:50 PM, Russ Allbery wrote: >> Jeffrey Altman writes: >>> I have a strong desire to ensure that everything that can be represented >>> in an NTFS file system can be represented in AFS. >> Does that include timestamps prior to 1970, just to check? > Yes. Okay, so you *do* care about what epoch is used, unless we use a time definition that allows for negative offsets from the epoch. Does Microsoft have documentation for how the Windows epoch deals with Gregorian calendar conversions and leap seconds? -- Russ Allbery (rra@stanford.edu) From shadow@gmail.com Mon Aug 1 19:19:11 2011 From: shadow@gmail.com (Derrick Brashear) Date: Mon, 1 Aug 2011 14:19:11 -0400 Subject: [AFS3-std] Re: A call for consensus on draft-deason-afs3-type-time-02 In-Reply-To: <20110801125344.e9e45873.adeason@sinenomine.net> References: <20110728135500.76B9ED@grand.central.org> <4E31776B.1040007@odu.edu> <87ei19yma5.fsf@windlord.stanford.edu> <20110729161932.18bc0ced.adeason@sinenomine.net> <87fwlotw4u.fsf@windlord.stanford.edu> <20110801122810.81b1889c.adeason@sinenomine.net> <20110801125344.e9e45873.adeason@sinenomine.net> Message-ID: On Mon, Aug 1, 2011 at 1:53 PM, Andrew Deason wrote: > On Mon, 1 Aug 2011 13:32:46 -0400 > Derrick Brashear wrote: > >> On Mon, Aug 1, 2011 at 1:28 PM, Andrew Deason wrote: >> >> >> b) the granularity >> > >> > This one I still have no idea on. I see reasons for both sides. >> >> So is there a reason an extended union with the various stamp >> granularities would be a nonstarter? In particular I'd suggest the >> draft strongly discourage >> sending a larger timestamp than actual information supports (e.g. >> don't use bits to send precision you don't have, rather than >> trailing-zero-padding a >> larger than needed number) > > Well, the objection to just having 64-bit seconds and 32-bit nanoseconds > is "space", and a union tag is an extra 32 bits... If we had a "100 NS > granularity" tag, then we'd have 100-ns granularity in 96 bits, whereas > now we could have 1-ns granularity in 96 bits. Unless there's some other > scheme you're thinking of that somehow makes this more efficient? for the worst case, it's worse. for the best case, it's better. but i suppose it may not be worth it given that the worst case will become more prevalent over time. > I had some kind of variable-length scheme that encoded the granularity > in the 'unused' bits of the value for coarser granularities, but I'm > pretty sure that only saved space for the *TimeRes types, and doesn't > really help for 'plain' times. and those are going to be a majority, i think. -- Derrick From tkeiser@sinenomine.net Mon Aug 1 21:16:44 2011 From: tkeiser@sinenomine.net (Tom Keiser) Date: Mon, 1 Aug 2011 16:16:44 -0400 Subject: [AFS3-std] Re: A call for consensus on draft-deason-afs3-type-time-02 In-Reply-To: <20110801125344.e9e45873.adeason@sinenomine.net> References: <20110728135500.76B9ED@grand.central.org> <4E31776B.1040007@odu.edu> <87ei19yma5.fsf@windlord.stanford.edu> <20110729161932.18bc0ced.adeason@sinenomine.net> <87fwlotw4u.fsf@windlord.stanford.edu> <20110801122810.81b1889c.adeason@sinenomine.net> <20110801125344.e9e45873.adeason@sinenomine.net> Message-ID: On Mon, Aug 1, 2011 at 1:53 PM, Andrew Deason wrote: > On Mon, 1 Aug 2011 13:32:46 -0400 > Derrick Brashear wrote: > >> On Mon, Aug 1, 2011 at 1:28 PM, Andrew Deason wrote: >> >> >> b) the granularity >> > >> > This one I still have no idea on. I see reasons for both sides. >> >> So is there a reason an extended union with the various stamp >> granularities would be a nonstarter? In particular I'd suggest the >> draft strongly discourage >> sending a larger timestamp than actual information supports (e.g. >> don't use bits to send precision you don't have, rather than >> trailing-zero-padding a >> larger than needed number) > > Well, the objection to just having 64-bit seconds and 32-bit nanoseconds > is "space", and a union tag is an extra 32 bits... If we had a "100 NS > granularity" tag, then we'd have 100-ns granularity in 96 bits, whereas > now we could have 1-ns granularity in 96 bits. Unless there's some other > scheme you're thinking of that somehow makes this more efficient? > This is why in Pittsburgh we proposed that overarching structures (e.g., AFSFetchStatus, and AFSStoreStatus) should be wrapped in ext-union, while proscribing the use of union/ext-union for individual members of those structures. As I suggested last Friday, we could define two different AFSFetchStatus/AFSStoreStatus implied legs for now: one with 64-bit time, and a second with 96-bit time (perhaps, we would also want to define a third leg with 32-bit time--given that we're likely to have implementations of the protocol long before server backing stores can handle the increased resolution)... -Tom From deengert@anl.gov Mon Aug 1 21:47:47 2011 From: deengert@anl.gov (Douglas E. Engert) Date: Mon, 01 Aug 2011 15:47:47 -0500 Subject: [AFS3-std] Election Procedure for AFS-3 Working Group Chairs Message-ID: <4E3710F3.3000603@anl.gov> http://tools.ietf.org/id/draft-wilkinson-afs3-standardisation-00.txt Says its time for an election, typically with nominations starting August 1, for 14 days, voting for 14 days, and 7 days to count with the new chair starting on October 1. It is my position that is up for election, as I have the one year term. Hartmut Reuter is the other co-chair with the 2 year term. Please read section 2.2.2 as to who can be nominated, and who can vote. (We will need a list of eligible voters, from the mailman-owner for our list. Once we get that we can start the nomination process, and keep within the guidelines and have a chair by October 1.) -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From jaltman@secure-endpoints.com Mon Aug 1 22:05:36 2011 From: jaltman@secure-endpoints.com (Jeffrey Altman) Date: Mon, 01 Aug 2011 17:05:36 -0400 Subject: [AFS3-std] Re: A call for consensus on draft-deason-afs3-type-time-02 In-Reply-To: <871ux580f5.fsf@windlord.stanford.edu> References: <20110728135500.76B9ED@grand.central.org> <4E31776B.1040007@odu.edu> <87ei19yma5.fsf@windlord.stanford.edu> <20110729161932.18bc0ced.adeason@sinenomine.net> <87fwlotw4u.fsf@windlord.stanford.edu> <87wrex836y.fsf@windlord.stanford.edu> <4E36E4D7.9010308@secure-endpoints.com> <87fwll81hg.fsf@windlord.stanford.edu> <4E36E9F5.9000502@secure-endpoints.com> <871ux580f5.fsf@windlord.stanford.edu> Message-ID: <4E371520.2050905@secure-endpoints.com> This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF4A4B8C5B5CC41684FB59F42 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 8/1/2011 2:13 PM, Russ Allbery wrote: > Okay, so you *do* care about what epoch is used, unless we use a time > definition that allows for negative offsets from the epoch. I am fine with negative offsets from epoch if that is what people want. > Does Microsoft have documentation for how the Windows epoch deals with > Gregorian calendar conversions and leap seconds? There isn't anything that pops out at me from Google. If you can provide me a list of boundary times to check I can construct a test application that uses SYSTEMTIME to FILETIME conversions to test the results of various time arithmetic operations. typedef struct _SYSTEMTIME { WORD wYear; WORD wMonth; WORD wDayOfWeek; WORD wDay; WORD wHour; WORD wMinute; WORD wSecond; WORD wMilliseconds; } SYSTEMTIME, *PSYSTEMTIME; --------------enigF4A4B8C5B5CC41684FB59F42 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iQEcBAEBAgAGBQJONxUiAAoJENxm1CNJffh4mu4H/A7+rbmqi6FER4MuMi1/q+SY lFwytYN63cqi9l0wcFnOohPlGYHF3NoKG8U71oZiTqLYdjG5mfi/BNQAU4Y+7aQ3 117nRk16TBN3UfdJo8dn/mapBOAlP9Cw9RF0Ac8z9f7416qZ/eHASAsyNiceOvwJ FsiQT9P03z2F+5zEb5/LUn6OGPNVHCB1HVv6TfeUM952Ksd/cmNBgozKlf+rBCDa iiunFEF/2sgHLlaT1iQgZ3TqgfulEJCRwnOSEaD6D+lVTZpCw7AT4UELa/JCNTJj gQ++cQnQ8PFGchd0t0IJhaoqFaAQqT+UZNMNbOvMTo9RkowPHlGqLJy5AbRF91M= =B2Sk -----END PGP SIGNATURE----- --------------enigF4A4B8C5B5CC41684FB59F42-- From shadow@gmail.com Mon Aug 1 22:07:45 2011 From: shadow@gmail.com (Derrick Brashear) Date: Mon, 1 Aug 2011 17:07:45 -0400 Subject: [AFS3-std] Re: A call for consensus on draft-deason-afs3-type-time-02 In-Reply-To: References: <20110728135500.76B9ED@grand.central.org> <4E31776B.1040007@odu.edu> <87ei19yma5.fsf@windlord.stanford.edu> <20110729161932.18bc0ced.adeason@sinenomine.net> <87fwlotw4u.fsf@windlord.stanford.edu> <20110801122810.81b1889c.adeason@sinenomine.net> <20110801125344.e9e45873.adeason@sinenomine.net> Message-ID: On Mon, Aug 1, 2011 at 4:16 PM, Tom Keiser wrote: > On Mon, Aug 1, 2011 at 1:53 PM, Andrew Deason wr= ote: >> On Mon, 1 Aug 2011 13:32:46 -0400 >> Derrick Brashear wrote: >> >>> On Mon, Aug 1, 2011 at 1:28 PM, Andrew Deason = wrote: >>> >>> >> b) the granularity >>> > >>> > This one I still have no idea on. I see reasons for both sides. >>> >>> So is there a reason an extended union with the various stamp >>> granularities would be a nonstarter? In particular I'd suggest the >>> draft strongly discourage >>> sending a larger timestamp than actual information supports (e.g. >>> don't use bits to send precision you don't have, rather than >>> trailing-zero-padding a >>> larger than needed number) >> >> Well, the objection to just having 64-bit seconds and 32-bit nanoseconds >> is "space", and a union tag is an extra 32 bits... If we had a "100 NS >> granularity" tag, then we'd have 100-ns granularity in 96 bits, whereas >> now we could have 1-ns granularity in 96 bits. Unless there's some other >> scheme you're thinking of that somehow makes this more efficient? >> > > This is why in Pittsburgh we proposed that overarching structures > (e.g., AFSFetchStatus, and AFSStoreStatus) should be wrapped in > ext-union, while proscribing the use of union/ext-union for individual > members of those structures. =A0As I suggested last Friday, we could > define two different AFSFetchStatus/AFSStoreStatus implied legs for > now: one with 64-bit time, and a second with 96-bit time (perhaps, we > would also want to define a third leg with 32-bit time--given that > we're likely to have implementations of the protocol long before > server backing stores can handle the increased resolution)... and this approach would be fine for this, at least for a long time in the interim. From rra@stanford.edu Mon Aug 1 22:16:18 2011 From: rra@stanford.edu (Russ Allbery) Date: Mon, 01 Aug 2011 14:16:18 -0700 Subject: [AFS3-std] Re: A call for consensus on draft-deason-afs3-type-time-02 In-Reply-To: <4E371520.2050905@secure-endpoints.com> (Jeffrey Altman's message of "Mon, 01 Aug 2011 17:05:36 -0400") References: <20110728135500.76B9ED@grand.central.org> <4E31776B.1040007@odu.edu> <87ei19yma5.fsf@windlord.stanford.edu> <20110729161932.18bc0ced.adeason@sinenomine.net> <87fwlotw4u.fsf@windlord.stanford.edu> <87wrex836y.fsf@windlord.stanford.edu> <4E36E4D7.9010308@secure-endpoints.com> <87fwll81hg.fsf@windlord.stanford.edu> <4E36E9F5.9000502@secure-endpoints.com> <871ux580f5.fsf@windlord.stanford.edu> <4E371520.2050905@secure-endpoints.com> Message-ID: <87livc6del.fsf@windlord.stanford.edu> Jeffrey Altman writes: > If you can provide me a list of boundary times to check I can construct > a test application that uses SYSTEMTIME to FILETIME conversions to test > the results of various time arithmetic operations. > typedef struct _SYSTEMTIME { > WORD wYear; > WORD wMonth; > WORD wDayOfWeek; > WORD wDay; > WORD wHour; > WORD wMinute; > WORD wSecond; > WORD wMilliseconds; > } SYSTEMTIME, *PSYSTEMTIME; Usually the interesting ones for Gregorian conversion of software written in the US are around the date of UK transition from Julian to Gregorian in September of 1752: September 1752 Su Mo Tu We Th Fr Sa 1 2 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 (gcal is one of the few programs I know that attempts to cope with this.) My guess is that Windows is using a backwards-projection of UTC without leap seconds and not attempting to worry about dates that theoretically should be in Julian, so you'll get an offset of 10 or 11 days relative to the actual historical time when converting from a timestamp to calendar time. -- Russ Allbery (rra@stanford.edu) From jaltman@secure-endpoints.com Mon Aug 1 22:20:06 2011 From: jaltman@secure-endpoints.com (Jeffrey Altman) Date: Mon, 01 Aug 2011 17:20:06 -0400 Subject: [AFS3-std] Re: A call for consensus on draft-deason-afs3-type-time-02 In-Reply-To: <87livc6del.fsf@windlord.stanford.edu> References: <20110728135500.76B9ED@grand.central.org> <4E31776B.1040007@odu.edu> <87ei19yma5.fsf@windlord.stanford.edu> <20110729161932.18bc0ced.adeason@sinenomine.net> <87fwlotw4u.fsf@windlord.stanford.edu> <87wrex836y.fsf@windlord.stanford.edu> <4E36E4D7.9010308@secure-endpoints.com> <87fwll81hg.fsf@windlord.stanford.edu> <4E36E9F5.9000502@secure-endpoints.com> <871ux580f5.fsf@windlord.stanford.edu> <4E371520.2050905@secure-endpoints.com> <87livc6del.fsf@windlord.stanford.edu> Message-ID: <4E371886.8010307@secure-endpoints.com> This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig2647EB98B812449AC7E31696 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 8/1/2011 5:16 PM, Russ Allbery wrote: > Jeffrey Altman writes: >=20 >> If you can provide me a list of boundary times to check I can construc= t >> a test application that uses SYSTEMTIME to FILETIME conversions to tes= t >> the results of various time arithmetic operations. >=20 >> typedef struct _SYSTEMTIME { >> WORD wYear; >> WORD wMonth; >> WORD wDayOfWeek; >> WORD wDay; >> WORD wHour; >> WORD wMinute; >> WORD wSecond; >> WORD wMilliseconds; >> } SYSTEMTIME, *PSYSTEMTIME; >=20 > Usually the interesting ones for Gregorian conversion of software writt= en > in the US are around the date of UK transition from Julian to Gregorian= in > September of 1752: >=20 > September 1752 > Su Mo Tu We Th Fr Sa > 1 2 14 15 16 > 17 18 19 20 21 22 23 > 24 25 26 27 28 29 30 >=20 > (gcal is one of the few programs I know that attempts to cope with this= =2E) >=20 > My guess is that Windows is using a backwards-projection of UTC without= > leap seconds and not attempting to worry about dates that theoretically= > should be in Julian, so you'll get an offset of 10 or 11 days relative = to > the actual historical time when converting from a timestamp to calendar= > time. >=20 Provide times for a few known leap seconds and I can test those as well. --------------enig2647EB98B812449AC7E31696 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iQEcBAEBAgAGBQJONxiIAAoJENxm1CNJffh49/AH/1MZZLyAQ9mIiabhFyZnFHuv FFjEX67+JHztWs7JmIZvz6vEFtrPggpRl2CFXC9kf5dT3eNckXMI3kMEaQRz+YUN cUats8XTrifl8BABP1u9n6xK8DWd3v+YBgrMumCn5ckVUzi+4VaQIrFqBqCfsig2 i2KN9IXVDtyHE5i0pcOxo6lmKYlgN1aMWh8gOSPXep/iQ13YvTWXBqrGxiGjzTLt rfz9AaySkkuVKbVGtRw/WIJn+P1J3MpfPnWWpEVHOfgFJp+1Gv0n5ILUYCpxxlV/ 0AOalh7nl+T/bQDR9oAfDL1kxwRCUCuO1mZbD9XLv+mdcbZ7/muv4PLLkhF85qw= =o4oS -----END PGP SIGNATURE----- --------------enig2647EB98B812449AC7E31696-- From rra@stanford.edu Mon Aug 1 22:30:35 2011 From: rra@stanford.edu (Russ Allbery) Date: Mon, 01 Aug 2011 14:30:35 -0700 Subject: [AFS3-std] Re: A call for consensus on draft-deason-afs3-type-time-02 In-Reply-To: <4E371886.8010307@secure-endpoints.com> (Jeffrey Altman's message of "Mon, 01 Aug 2011 17:20:06 -0400") References: <20110728135500.76B9ED@grand.central.org> <4E31776B.1040007@odu.edu> <87ei19yma5.fsf@windlord.stanford.edu> <20110729161932.18bc0ced.adeason@sinenomine.net> <87fwlotw4u.fsf@windlord.stanford.edu> <87wrex836y.fsf@windlord.stanford.edu> <4E36E4D7.9010308@secure-endpoints.com> <87fwll81hg.fsf@windlord.stanford.edu> <4E36E9F5.9000502@secure-endpoints.com> <871ux580f5.fsf@windlord.stanford.edu> <4E371520.2050905@secure-endpoints.com> <87livc6del.fsf@windlord.stanford.edu> <4E371886.8010307@secure-endpoints.com> Message-ID: <87bow86cqs.fsf@windlord.stanford.edu> Jeffrey Altman writes: > Provide times for a few known leap seconds and I can test those as well. Leap seconds are always added as 23:60 on June 30th or December 31st. There's a table at: http://en.wikipedia.org/wiki/Leap_second of all the leap seconds that have been added historically. So: 1972-06-30 23:59:59 1972-06-30 23:59:60 1972-07-01 00:00:00 for example. One of the interesting questions is whether conversion of the first and last calendar times above are, when represented as timestamps, one second apart or two seconds apart. Note that, in POSIX, they're one second apart, because POSIX time contains no leap seconds by definition (which means that it's not really possible to accurately represent those dates). On UNIX systems, using mktime on those dates will generally convert as follows: 1972-06-30 23:59:59 78821999 1972-06-30 23:59:60 78822000 1972-07-01 00:00:00 78822000 There's not really a "right" answer here; we just need to say what the answer is. -- Russ Allbery (rra@stanford.edu) From jhutz@cmu.edu Tue Aug 2 00:17:16 2011 From: jhutz@cmu.edu (Jeffrey Hutzelman) Date: Mon, 01 Aug 2011 19:17:16 -0400 Subject: [AFS3-std] Re: Election Procedure for AFS-3 Working Group Chairs In-Reply-To: <4E3710F3.3000603@anl.gov> References: <4E3710F3.3000603@anl.gov> Message-ID: <1312240636.3168.25.camel@destiny.pc.cs.cmu.edu> On Mon, 2011-08-01 at 15:47 -0500, Douglas E. Engert wrote: > http://tools.ietf.org/id/draft-wilkinson-afs3-standardisation-00.txt > > Says its time for an election, typically with nominations starting > August 1, for 14 days, voting for 14 days, and 7 days to count with > the new chair starting on October 1. > > It is my position that is up for election, as I have the one year > term. Hartmut Reuter is the other co-chair with the 2 year term. > > Please read section 2.2.2 as to who can be nominated, and who can vote. > > (We will need a list of eligible voters, from the mailman-owner > for our list. Once we get that we can start the nomination process, > and keep within the guidelines and have a chair by October 1.) According to section 2.2.2, the list of eligible voters consists of anyone who has posted or was subscribed during the period from June 1 to July 1. It's fairly easy to construct a list of who has posted by consulting the list archives, which are publicly available at https://lists.openafs.org/pipermail/afs3-standardization/ The subscriber list is not public; however, any subscriber can obtain a copy by filling in his username and password near the bottom of the page at https://lists.openafs.org/mailman/listinfo/afs3-standardization and selecting "Visit Subscriber List". Of course, that's as of today. To build a voter list, you also need to know that there have been no new subscribers and no one has unsubscribed since April 25, before the start of the eligibility period. -- Jeff From deengert@anl.gov Tue Aug 2 17:26:34 2011 From: deengert@anl.gov (Douglas E. Engert) Date: Tue, 02 Aug 2011 11:26:34 -0500 Subject: [AFS3-std] Call for nomination for the position of AFS3-standardization co-chair Message-ID: <4E38253A.6000001@anl.gov> http://tools.ietf.org/id/draft-wilkinson-afs3-standardisation-00.txt defines our election procedures to elect a co-chair. It is my position that is up for election, as I have the one year term. Hartmut Reuter is the other co-chair with the 2 year term, due to expire next year. Schedule: Nominations open 8/2 - 8/16 Announcement of nominations 8/17 Voting 8-17 - 8/31 Election results 9/7 Please read section 2.2.2 as to who can be nominated, and who can vote. Send nominations to Hartmut and myself as the vote takers, and we can contact the potential nominees to make sure they are willing to serve. As Jeff points out: > The subscriber list is not public; however, any subscriber can obtain a > copy by filling in his username and password near the bottom of the page > at https://lists.openafs.org/mailman/listinfo/afs3-standardization and > selecting "Visit Subscriber List". Of course, that's as of today. To > build a voter list, you also need to know that there have been no new > subscribers and no one has unsubscribed since April 25, before the start > of the eligibility period. (You can also get your password sent to you with the "Edit Options") -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From deengert@anl.gov Fri Aug 5 20:32:15 2011 From: deengert@anl.gov (Douglas E. Engert) Date: Fri, 05 Aug 2011 14:32:15 -0500 Subject: [AFS3-std] Call for nomination for the position of AFS3-standardization co-chair In-Reply-To: <4E38253A.6000001@anl.gov> References: <4E38253A.6000001@anl.gov> Message-ID: <4E3C453F.5060805@anl.gov> I am not running for re-election and so far we have receive only one other nomination. See the schedule below. On 8/2/2011 11:26 AM, Douglas E. Engert wrote: > http://tools.ietf.org/id/draft-wilkinson-afs3-standardisation-00.txt > > defines our election procedures to elect a co-chair. It is my position > that is up for election, as I have the one year term. Hartmut Reuter > is the other co-chair with the 2 year term, due to expire next year. > > Schedule: > Nominations open 8/2 - 8/16 > Announcement of nominations 8/17 > Voting 8-17 - 8/31 > Election results 9/7 > > Please read section 2.2.2 as to who can be nominated, and who can vote. > > Send nominations to Hartmut and myself as the vote takers, and we can > contact the potential nominees to make sure they are willing to serve. > > As Jeff points out: > > The subscriber list is not public; however, any subscriber can obtain a > > copy by filling in his username and password near the bottom of the page > > at https://lists.openafs.org/mailman/listinfo/afs3-standardization and > > selecting "Visit Subscriber List". Of course, that's as of today. To > > build a voter list, you also need to know that there have been no new > > subscribers and no one has unsubscribed since April 25, before the start > > of the eligibility period. > > (You can also get your password sent to you with the "Edit Options") > -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From adeason@sinenomine.net Mon Aug 8 18:32:58 2011 From: adeason@sinenomine.net (Andrew Deason) Date: Mon, 8 Aug 2011 12:32:58 -0500 Subject: [AFS3-std] Re: A call for consensus on draft-deason-afs3-type-time-02 References: <20110728135500.76B9ED@grand.central.org> <4E31776B.1040007@odu.edu> <87ei19yma5.fsf@windlord.stanford.edu> <20110729161932.18bc0ced.adeason@sinenomine.net> <87fwlotw4u.fsf@windlord.stanford.edu> Message-ID: <20110808123258.59cc0539.adeason@sinenomine.net> On Fri, 29 Jul 2011 18:06:25 -0700 Russ Allbery wrote: > Or, hm, I suppose if you squint at it right, you can decide that > "number of seconds" isn't just elapsed actual time, but includes the > leap seconds that were inserted. Which would also work for our > phrasing. Maybe we could just say that explicitly. Something like: > > the number of seconds and nanoseconds since midnight or 0 hour > January 1, 1970 Coordinated Universal Time (UTC), including any > leap seconds inserted into UTC. It's very possible I am backwards on this, but shouldn't this be "excluding any leap seconds"? That is, in our time representation, there is a difference of 1 "second" (however we define "second") between the times 31 Dec 2005 23:59:59 and 01 Jan 2006 00:00:00, even though there was a leap second at 31 Dec 2005 23:59:60. That is, I thought we'd be following UTC more than TAI. And also, I did find another instance of this being mentioned in IETF RFCs. RFC 4049 states in Section 2 (at the top of the second page): The integer value is the number of seconds, excluding leap seconds, after midnight UTC, January 1, 1970. Would that work for us? -- Andrew Deason adeason@sinenomine.net From rra@stanford.edu Mon Aug 8 18:50:11 2011 From: rra@stanford.edu (Russ Allbery) Date: Mon, 08 Aug 2011 10:50:11 -0700 Subject: [AFS3-std] Re: A call for consensus on draft-deason-afs3-type-time-02 In-Reply-To: <20110808123258.59cc0539.adeason@sinenomine.net> (Andrew Deason's message of "Mon, 8 Aug 2011 12:32:58 -0500") References: <20110728135500.76B9ED@grand.central.org> <4E31776B.1040007@odu.edu> <87ei19yma5.fsf@windlord.stanford.edu> <20110729161932.18bc0ced.adeason@sinenomine.net> <87fwlotw4u.fsf@windlord.stanford.edu> <20110808123258.59cc0539.adeason@sinenomine.net> Message-ID: <8762m7ztbg.fsf@windlord.stanford.edu> Andrew Deason writes: > Russ Allbery wrote: >> Or, hm, I suppose if you squint at it right, you can decide that >> "number of seconds" isn't just elapsed actual time, but includes the >> leap seconds that were inserted. Which would also work for our >> phrasing. Maybe we could just say that explicitly. Something like: >> >> the number of seconds and nanoseconds since midnight or 0 hour >> January 1, 1970 Coordinated Universal Time (UTC), including any >> leap seconds inserted into UTC. > It's very possible I am backwards on this, but shouldn't this be > "excluding any leap seconds"? Oh, yes, you're exactly right. Thank you. > That is, in our time representation, there is a difference of 1 "second" > (however we define "second") between the times 31 Dec 2005 23:59:59 and > 01 Jan 2006 00:00:00, even though there was a leap second at 31 Dec 2005 > 23:59:60. That is, I thought we'd be following UTC more than TAI. Yes, correct. > And also, I did find another instance of this being mentioned in IETF > RFCs. RFC 4049 states in Section 2 (at the top of the second page): > The integer value is the number of seconds, excluding leap seconds, > after midnight UTC, January 1, 1970. > Would that work for us? That sounds great to me. We could take the same approach if we use the other epoch, although I think we should be more wordy about it: The integer value is the number of seconds, excluding leap seconds, after midnight, January 1, 1601 Coordinated Universal Time (UTC), in the Gregorian calendar. NOTE: Neither the Gregorian calendar or the modern UTC time zone were in use in most of the world at that date, but times are represented as if they were, using the obvious backwards projection of the current UTC time zone and Gregorian calendar rules to January 1, 1601. Be aware that any real-world times from that era will likely require Julian to Gregorian calendar conversions to be represented in this format and probably cannot be simply converted using normal time conversions from the modern era. I think that phrasing would resolve my objections to the epoch, along with the additional bits that are in the current draft about how to convert. -- Russ Allbery (rra@stanford.edu) From adeason@sinenomine.net Mon Aug 8 18:54:03 2011 From: adeason@sinenomine.net (Andrew Deason) Date: Mon, 8 Aug 2011 12:54:03 -0500 Subject: [AFS3-std] Re: A call for consensus on draft-deason-afs3-type-time-02 References: <4E2082C6.80609@anl.gov> Message-ID: <20110808125403.f9b913b3.adeason@sinenomine.net> On Fri, 15 Jul 2011 13:11:18 -0500 "Douglas E. Engert" wrote: > http://datatracker.ietf.org/doc/draft-deason-afs3-type-time/ Based on the threads in afs3-stds, and on discussions I've had with others, I propose the following going forward. This is what I'm working on for an -03 draft, and it's what will appear unless I hear objections. The epoch will be changed to the Unix epoch. Absolute time will be signed so we can still represent the windows stuff. The language will also be changed a bit according to Russ's suggestions ("number of seconds since 1970 excluding leap seconds" or whatever it turns out to be, see this sub-thread: ). The granularity in this draft will not be changed. However, additional types will be proposed to be used for higher efficiency and higher granularity. That is, the current types will be AFSAbsTime64 which corresponds to 64-bit 100-ns time, but we will also have types such as AFSAbsTime32 (32-bit 1-s time) and AFSAbsTime96 (64-bit 1-s time plus 32-bit 1-ns). RPCs for which this matters will use some way of accomodating and specifying these other types, but how they do so is outside the scope of this draft (in theory this could be unions, extended unions, separate RPCs etc; in practice right now we expect extended unions). In the interest of getting this i-d done as quickly as we can, the other time types will not be added to this draft, but will be proposed in separate i-ds and if we need to we can argue about them then. So, the only change for draft-deason-afs3-type-time is that the type names will be changed to AFSAbsTime64 etc, and I will include a paragraph discussing the rationale and the future use of other time types for interoperability and efficiency. I feel this will satisfy everyone's concerns, as this approach should allow us to interoperate well with other systems, but the common case should be kept nearly as efficient as the current draft. -- Andrew Deason adeason@sinenomine.net From adeason@sinenomine.net Mon Aug 8 18:58:57 2011 From: adeason@sinenomine.net (Andrew Deason) Date: Mon, 8 Aug 2011 12:58:57 -0500 Subject: [AFS3-std] Re: A call for consensus on draft-deason-afs3-type-time-02 References: <20110728135500.76B9ED@grand.central.org> <4E31776B.1040007@odu.edu> <87ei19yma5.fsf@windlord.stanford.edu> <20110729161932.18bc0ced.adeason@sinenomine.net> <87fwlotw4u.fsf@windlord.stanford.edu> <20110808123258.59cc0539.adeason@sinenomine.net> <8762m7ztbg.fsf@windlord.stanford.edu> Message-ID: <20110808125857.a055922a.adeason@sinenomine.net> On Mon, 08 Aug 2011 10:50:11 -0700 Russ Allbery wrote: > We could take the same approach if we use the other epoch, although I > think we should be more wordy about it: Oh, I thought we'd just use the Unix epoch since it just makes some of this easier. A note on converting to pre-UTC dates seems good, though. Also just by the way, NTPv4 apparently uses an epoch in 1900. They have this to say about it in RFC 5905: In the date and timestamp formats, the prime epoch, or base date of era 0, is 0 h 1 January 1900 UTC, when all bits are zero. It should be noted that strictly speaking, UTC did not exist prior to 1 January 1972, but it is convenient to assume it has existed for all eternity, even if all knowledge of historic leap seconds has been lost. -- Andrew Deason adeason@sinenomine.net From rra@stanford.edu Mon Aug 8 20:50:40 2011 From: rra@stanford.edu (Russ Allbery) Date: Mon, 08 Aug 2011 12:50:40 -0700 Subject: [AFS3-std] Re: A call for consensus on draft-deason-afs3-type-time-02 In-Reply-To: <20110808125857.a055922a.adeason@sinenomine.net> (Andrew Deason's message of "Mon, 8 Aug 2011 12:58:57 -0500") References: <20110728135500.76B9ED@grand.central.org> <4E31776B.1040007@odu.edu> <87ei19yma5.fsf@windlord.stanford.edu> <20110729161932.18bc0ced.adeason@sinenomine.net> <87fwlotw4u.fsf@windlord.stanford.edu> <20110808123258.59cc0539.adeason@sinenomine.net> <8762m7ztbg.fsf@windlord.stanford.edu> <20110808125857.a055922a.adeason@sinenomine.net> Message-ID: <87k4any967.fsf@windlord.stanford.edu> Andrew Deason writes: > Russ Allbery wrote: >> We could take the same approach if we use the other epoch, although I >> think we should be more wordy about it: > Oh, I thought we'd just use the Unix epoch since it just makes some of > this easier. A note on converting to pre-UTC dates seems good, though. Jeffrey has a good point, though: we lose representability of dates that can currently be handled with CIFS. > Also just by the way, NTPv4 apparently uses an epoch in 1900. They have > this to say about it in RFC 5905: > In the date and timestamp formats, the prime epoch, or base date of > era 0, is 0 h 1 January 1900 UTC, when all bits are zero. It should > be noted that strictly speaking, UTC did not exist prior to 1 > January 1972, but it is convenient to assume it has existed for all > eternity, even if all knowledge of historic leap seconds has been > lost. Yeah, that's similar in intention to my note. -- Russ Allbery (rra@stanford.edu) From adeason@sinenomine.net Mon Aug 8 21:42:13 2011 From: adeason@sinenomine.net (Andrew Deason) Date: Mon, 8 Aug 2011 15:42:13 -0500 Subject: [AFS3-std] Re: A call for consensus on draft-deason-afs3-type-time-02 References: <20110728135500.76B9ED@grand.central.org> <4E31776B.1040007@odu.edu> <87ei19yma5.fsf@windlord.stanford.edu> <20110729161932.18bc0ced.adeason@sinenomine.net> <87fwlotw4u.fsf@windlord.stanford.edu> <20110808123258.59cc0539.adeason@sinenomine.net> <8762m7ztbg.fsf@windlord.stanford.edu> <20110808125857.a055922a.adeason@sinenomine.net> <87k4any967.fsf@windlord.stanford.edu> Message-ID: <20110808154213.4ce21908.adeason@sinenomine.net> On Mon, 08 Aug 2011 12:50:40 -0700 Russ Allbery wrote: > Andrew Deason writes: > > Oh, I thought we'd just use the Unix epoch since it just makes some > > of this easier. A note on converting to pre-UTC dates seems good, > > though. > > Jeffrey has a good point, though: we lose representability of dates > that can currently be handled with CIFS. Then we just make the absolute timestamps signed. It just seems better to me to start from an epoch that's a bit more well-defined (or at least, more easily well-defined; we can always define 1 Jan 1600 as X seconds before 1 Jan 1970, but that seems strangely indirect). -- Andrew Deason adeason@sinenomine.net From rra@stanford.edu Mon Aug 8 21:49:42 2011 From: rra@stanford.edu (Russ Allbery) Date: Mon, 08 Aug 2011 13:49:42 -0700 Subject: [AFS3-std] Re: A call for consensus on draft-deason-afs3-type-time-02 In-Reply-To: <20110808154213.4ce21908.adeason@sinenomine.net> (Andrew Deason's message of "Mon, 8 Aug 2011 15:42:13 -0500") References: <20110728135500.76B9ED@grand.central.org> <4E31776B.1040007@odu.edu> <87ei19yma5.fsf@windlord.stanford.edu> <20110729161932.18bc0ced.adeason@sinenomine.net> <87fwlotw4u.fsf@windlord.stanford.edu> <20110808123258.59cc0539.adeason@sinenomine.net> <8762m7ztbg.fsf@windlord.stanford.edu> <20110808125857.a055922a.adeason@sinenomine.net> <87k4any967.fsf@windlord.stanford.edu> <20110808154213.4ce21908.adeason@sinenomine.net> Message-ID: <87sjpbwrvd.fsf@windlord.stanford.edu> Andrew Deason writes: > Russ Allbery wrote: >> Jeffrey has a good point, though: we lose representability of dates >> that can currently be handled with CIFS. > Then we just make the absolute timestamps signed. It just seems better > to me to start from an epoch that's a bit more well-defined (or at > least, more easily well-defined; we can always define 1 Jan 1600 as X > seconds before 1 Jan 1970, but that seems strangely indirect). I guess I'm ambivalent between signed timestamps and the Windows epoch. Both of them are going to be at least somewhat unusual for typical UNIX code. My guess is that it will be easier to explain the Windows epoch than it will be to explain signed arithmetic on times, but I could be wrong. -- Russ Allbery (rra@stanford.edu) From jaltman@secure-endpoints.com Mon Aug 8 22:25:48 2011 From: jaltman@secure-endpoints.com (Jeffrey Altman) Date: Mon, 08 Aug 2011 17:25:48 -0400 Subject: [AFS3-std] Re: A call for consensus on draft-deason-afs3-type-time-02 In-Reply-To: <20110808154213.4ce21908.adeason@sinenomine.net> References: <20110728135500.76B9ED@grand.central.org> <4E31776B.1040007@odu.edu> <87ei19yma5.fsf@windlord.stanford.edu> <20110729161932.18bc0ced.adeason@sinenomine.net> <87fwlotw4u.fsf@windlord.stanford.edu> <20110808123258.59cc0539.adeason@sinenomine.net> <8762m7ztbg.fsf@windlord.stanford.edu> <20110808125857.a055922a.adeason@sinenomine.net> <87k4any967.fsf@windlord.stanford.edu> <20110808154213.4ce21908.adeason@sinenomine.net> Message-ID: <4E40545C.6080600@secure-endpoints.com> This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig4AFFD422C27516B82CF3A430 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 8/8/2011 4:42 PM, Andrew Deason wrote: > On Mon, 08 Aug 2011 12:50:40 -0700 > Russ Allbery wrote: >=20 >> Andrew Deason writes: >>> Oh, I thought we'd just use the Unix epoch since it just makes some >>> of this easier. A note on converting to pre-UTC dates seems good, >>> though. >> >> Jeffrey has a good point, though: we lose representability of dates >> that can currently be handled with CIFS. >=20 > Then we just make the absolute timestamps signed. It just seems better > to me to start from an epoch that's a bit more well-defined (or at > least, more easily well-defined; we can always define 1 Jan 1600 as X > seconds before 1 Jan 1970, but that seems strangely indirect). I don't have a strong feeling about the epoch. I am fine with negative timestamp values. --------------enig4AFFD422C27516B82CF3A430 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iQEcBAEBAgAGBQJOQFRfAAoJENxm1CNJffh41zQH/1a3yikgeEdDGPesg+i901Bu vj/9ivedJ558iUUp4IuR4lC+JB236gh9AH0Mb5lt3FTPkfkX7nM+K9ZH5zDHFhSO O+6TPvMtogJZi94yB7O/1M0cWy+D2NbY+glWBtZCzzOYf1xOyrgSozr+D6xwykS/ pVE8NpJ4zApX/94d1pNWXa+wIRSQO1RTJ2nQR8hLCMGUFaQapwKmpAPKhglKJFFH Jl9gvt9Pb5eCFiqq5VO+ps49Ny8lCYL/49HMeF1jGSJyWs8cDJklKq3BFCn5ansd HzN0ksSlJC6YRlj12EtacdoG0hrym2+BNCMNh2MdPduR24av5D7Aiur0b2rrWb4= =47yu -----END PGP SIGNATURE----- --------------enig4AFFD422C27516B82CF3A430-- From deengert@anl.gov Wed Aug 10 13:48:38 2011 From: deengert@anl.gov (Douglas E. Engert) Date: Wed, 10 Aug 2011 07:48:38 -0500 Subject: [AFS3-std] Call for nomination for the position of AFS3-standardization co-chair In-Reply-To: <4E38253A.6000001@anl.gov> References: <4E38253A.6000001@anl.gov> Message-ID: <4E427E26.9040009@anl.gov> Let me restate this again, we have received only one nomination, so I have also nominated 2 people. We are waiting for these 3 people to respond that they would be willing to run. So please send in nominations to Hartmut and myself. On 8/2/2011 11:26 AM, Douglas E. Engert wrote: > http://tools.ietf.org/id/draft-wilkinson-afs3-standardisation-00.txt > > defines our election procedures to elect a co-chair. It is my position > that is up for election, as I have the one year term. Hartmut Reuter > is the other co-chair with the 2 year term, due to expire next year. > > Schedule: > Nominations open 8/2 - 8/16 > Announcement of nominations 8/17 > Voting 8-17 - 8/31 > Election results 9/7 > > Please read section 2.2.2 as to who can be nominated, and who can vote. > > Send nominations to Hartmut and myself as the vote takers, and we can > contact the potential nominees to make sure they are willing to serve. > > As Jeff points out: > > The subscriber list is not public; however, any subscriber can obtain a > > copy by filling in his username and password near the bottom of the page > > at https://lists.openafs.org/mailman/listinfo/afs3-standardization and > > selecting "Visit Subscriber List". Of course, that's as of today. To > > build a voter list, you also need to know that there have been no new > > subscribers and no one has unsubscribed since April 25, before the start > > of the eligibility period. > > (You can also get your password sent to you with the "Edit Options") > -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 _______________________________________________ AFS3-standardization mailing list AFS3-standardization@openafs.org http://lists.openafs.org/mailman/listinfo/afs3-standardization From jhutz@cmu.edu Wed Aug 10 13:58:17 2011 From: jhutz@cmu.edu (Jeffrey Hutzelman) Date: Wed, 10 Aug 2011 08:58:17 -0400 Subject: [AFS3-std] Call for nomination for the position of AFS3-standardization co-chair In-Reply-To: <4E427E26.9040009@anl.gov> References: <4E38253A.6000001@anl.gov> <4E427E26.9040009@anl.gov> Message-ID: <1312981097.3168.159.camel@destiny.pc.cs.cmu.edu> On Wed, 2011-08-10 at 07:48 -0500, Douglas E. Engert wrote: > Let me restate this again, we have received only one nomination, > so I have also nominated 2 people. We are waiting for these 3 > people to respond that they would be willing to run. Per 2.2.2, nominations are supposed to be sent to this mailing list, and each nomination should be made and seconded by eligible voters. I don't see that any nominations have gone to the list so far. It would be good if those who have already made nominations would copy them to the list; otherwise it will be hard to get a second. :-) -- Jeff From deengert@anl.gov Wed Aug 10 14:08:24 2011 From: deengert@anl.gov (Douglas E. Engert) Date: Wed, 10 Aug 2011 08:08:24 -0500 Subject: [AFS3-std] Call for nomination for the position of AFS3-standardization co-chair In-Reply-To: <1312981097.3168.159.camel@destiny.pc.cs.cmu.edu> References: <4E38253A.6000001@anl.gov> <4E427E26.9040009@anl.gov> <1312981097.3168.159.camel@destiny.pc.cs.cmu.edu> Message-ID: <4E4282C8.8030702@anl.gov> On 8/10/2011 7:58 AM, Jeffrey Hutzelman wrote: > On Wed, 2011-08-10 at 07:48 -0500, Douglas E. Engert wrote: >> Let me restate this again, we have received only one nomination, >> so I have also nominated 2 people. We are waiting for these 3 >> people to respond that they would be willing to run. > > Per 2.2.2, nominations are supposed to be sent to this mailing list, and > each nomination should be made and seconded by eligible voters. I don't > see that any nominations have gone to the list so far. It would be good > if those who have already made nominations would copy them to the list; > otherwise it will be hard to get a second. :-) Good point. So far no one has indicated that they are "Any consenting individual" so I have not put their name out. The other note sent to the vote takers, gave a name, and I am waiting for a reply as to weither that individual is willing. > > -- Jeff > > -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From deengert@anl.gov Wed Aug 10 14:45:50 2011 From: deengert@anl.gov (Douglas E. Engert) Date: Wed, 10 Aug 2011 08:45:50 -0500 Subject: [AFS3-std] Call for nomination for the position of AFS3-standardization co-chair In-Reply-To: <4E38253A.6000001@anl.gov> References: <4E38253A.6000001@anl.gov> Message-ID: <4E428B8E.9040602@anl.gov> I (as a group member, not as co-chair) would like to place in nomination for the co-chair of the AFS3-standardization group, Jeffrey Hutzelman. Jeff's IETF experiences, knowledge of AFS, and organizations skills make him an ideal candidate for the position. On 8/2/2011 11:26 AM, Douglas E. Engert wrote: > http://tools.ietf.org/id/draft-wilkinson-afs3-standardisation-00.txt > > defines our election procedures to elect a co-chair. It is my position > that is up for election, as I have the one year term. Hartmut Reuter > is the other co-chair with the 2 year term, due to expire next year. > > Schedule: > Nominations open 8/2 - 8/16 > Announcement of nominations 8/17 > Voting 8-17 - 8/31 > Election results 9/7 > > Please read section 2.2.2 as to who can be nominated, and who can vote. > > Send nominations to Hartmut and myself as the vote takers, and we can > contact the potential nominees to make sure they are willing to serve. > > As Jeff points out: > > The subscriber list is not public; however, any subscriber can obtain a > > copy by filling in his username and password near the bottom of the page > > at https://lists.openafs.org/mailman/listinfo/afs3-standardization and > > selecting "Visit Subscriber List". Of course, that's as of today. To > > build a voter list, you also need to know that there have been no new > > subscribers and no one has unsubscribed since April 25, before the start > > of the eligibility period. > > (You can also get your password sent to you with the "Edit Options") > -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From matt@linuxbox.com Wed Aug 10 15:10:02 2011 From: matt@linuxbox.com (Matt W. Benjamin) Date: Wed, 10 Aug 2011 10:10:02 -0400 (EDT) Subject: [AFS3-std] Call for nomination for the position of AFS3-standardization co-chair In-Reply-To: <4E428B8E.9040602@anl.gov> Message-ID: <562730635.18.1312985402484.JavaMail.root@thunderbeast.private.linuxbox.com> Second. ----- "Douglas E. Engert" wrote: > I (as a group member, not as co-chair) would like to place in > nomination > for the co-chair of the AFS3-standardization group, Jeffrey > Hutzelman. > > Jeff's IETF experiences, knowledge of AFS, and > organizations skills make him an ideal candidate for the position. > > -- Matt Benjamin The Linux Box 206 South Fifth Ave. Suite 150 Ann Arbor, MI 48104 http://linuxbox.com tel. 734-761-4689 fax. 734-769-8938 cel. 734-216-5309 From jaltman@secure-endpoints.com Wed Aug 10 16:00:04 2011 From: jaltman@secure-endpoints.com (Jeffrey Altman) Date: Wed, 10 Aug 2011 11:00:04 -0400 Subject: [AFS3-std] Call for nomination for the position of AFS3-standardization co-chair In-Reply-To: <562730635.18.1312985402484.JavaMail.root@thunderbeast.private.linuxbox.com> References: <562730635.18.1312985402484.JavaMail.root@thunderbeast.private.linuxbox.com> Message-ID: <4E429CF4.5060705@secure-endpoints.com> This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig4E96346D395F7DE12DCC99A3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 8/10/2011 10:10 AM, Matt W. Benjamin wrote: > Second. >=20 > ----- "Douglas E. Engert" wrote: >=20 >> I (as a group member, not as co-chair) would like to place in >> nomination >> for the co-chair of the AFS3-standardization group, Jeffrey >> Hutzelman. >> >> Jeff's IETF experiences, knowledge of AFS, and >> organizations skills make him an ideal candidate for the position. >> >> I believe that Jeff would make an excellent chair (if he has time) but would prefer that the Chair not also be a registrar. --------------enig4E96346D395F7DE12DCC99A3 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iQEcBAEBAgAGBQJOQpz3AAoJENxm1CNJffh4YcYH/2UAYaa+ASU7rCdoqMODFk1D efEUmqC1fwllQ+RCfTLzBJdLUM/9a0tT4/EPmKtfQ+TqGAAfe56ncmykpwDsSM+w qsNOPxC+5J9YpAi9CCsNx0i6ynuTAd7i/pLrxl2ZbBGIgHXcTx+GqVLneummsdvb I4KLDxYYIZOhz6LTywKZBIfrm5JuO3SUI1W8JQ+1BbTXjyRl6u+N5qW+8p4JGy0q G7ZXnLMmJwYuW8XqaJqG+q0LOuGiKcggYX9Gzs9o4lGp0B+l0Jf2LftM1Vp8epUO aBAVyhW7MF3tZQEys3K0/r6GVnSiQqJuAB01FTzD5M86wdsnuLp7XW/njYcuy+Y= =EpGd -----END PGP SIGNATURE----- --------------enig4E96346D395F7DE12DCC99A3-- From deengert@anl.gov Wed Aug 10 16:22:50 2011 From: deengert@anl.gov (Douglas E. Engert) Date: Wed, 10 Aug 2011 10:22:50 -0500 Subject: [AFS3-std] Call for nomination for the position of AFS3-standardization co-chair In-Reply-To: <4E429CF4.5060705@secure-endpoints.com> References: <562730635.18.1312985402484.JavaMail.root@thunderbeast.private.linuxbox.com> <4E429CF4.5060705@secure-endpoints.com> Message-ID: <4E42A24A.6090206@anl.gov> On 8/10/2011 10:00 AM, Jeffrey Altman wrote: > On 8/10/2011 10:10 AM, Matt W. Benjamin wrote: >> Second. >> >> ----- "Douglas E. Engert" wrote: >> >>> I (as a group member, not as co-chair) would like to place in >>> nomination >>> for the co-chair of the AFS3-standardization group, Jeffrey >>> Hutzelman. >>> >>> Jeff's IETF experiences, knowledge of AFS, and >>> organizations skills make him an ideal candidate for the position. >>> >>> > > I believe that Jeff would make an excellent chair (if he has time) but > would prefer that the Chair not also be a registrar. I understand. Section 2.3.2 says: "it is proposed to extend the role of registrar to include a number of individuals from the community." So the work could be spread around if that is the issue. > > -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From scs@umich.edu Wed Aug 10 16:53:37 2011 From: scs@umich.edu (Steve Simmons) Date: Wed, 10 Aug 2011 11:53:37 -0400 Subject: [AFS3-std] Re: A call for consensus on draft-deason-afs3-type-time-02 In-Reply-To: <87bow86cqs.fsf@windlord.stanford.edu> References: <20110728135500.76B9ED@grand.central.org> <4E31776B.1040007@odu.edu> <87ei19yma5.fsf@windlord.stanford.edu> <20110729161932.18bc0ced.adeason@sinenomine.net> <87fwlotw4u.fsf@windlord.stanford.edu> <87wrex836y.fsf@windlord.stanford.edu> <4E36E4D7.9010308@secure-endpoints.com> <87fwll81hg.fsf@windlord.stanford.edu> <4E36E9F5.9000502@secure-endpoints.com> <871ux580f5.fsf@windlord.stanford.edu> <4E371520.2050905@secure-endpoints.com> <87livc6del.fsf@windlord.stanford.edu> <4E371886.8010307@secure-endpoints.com> <87bow86cqs.fsf@windlord.stanford.edu> Message-ID: <11B3F212-2286-4452-9917-88D390C380BD@umich.edu> On Aug 1, 2011, at 5:30 PM, Russ Allbery wrote: > . . . One of the interesting questions is whether conversion of > the first and last calendar times above are, when represented as > timestamps, one second apart or two seconds apart. >=20 > Note that, in POSIX, they're one second apart, because POSIX time = contains > no leap seconds by definition (which means that it's not really = possible > to accurately represent those dates). >=20 > On UNIX systems, using mktime on those dates will generally convert as > follows: >=20 > 1972-06-30 23:59:59 78821999 > 1972-06-30 23:59:60 78822000 > 1972-07-01 00:00:00 78822000 >=20 > There's not really a "right" answer here; we just need to say what the > answer is. The last paragraph says it, both w/r/t the POSIX issues above and the = various other time issues discussed in this thread. We don't need to be = absolutely right*, nor do we necessarily need to be fully in agreement = with any other vendor or standards system. We just need to say what we = are doing. I proposed we be broken in the same way POSIX is broken, rather than = being any other brand of broken or inventing our own. :-) Steve * IMHO 'absolutely right' would involved knowing what is right, and = presenting to all the other broken implementations their expected broken = data. The former is beyond our scope and abilities, the latter . . . = well, that way lies madness. Let's face it, 99.99% of the time all we're = talking about are filesystem timestamps. If someone wants to touch a = file with the date Sept 10 1752 and not specify anything else about how = to interpret that date, they deserve the wrongness they get. And anybody = who's doing work where leap seconds and calendar type transitions matter = is not doing it using POSIX, Windows, or any other OS-time = representation.** ** No, I have no freaking idea what they're using.= From deengert@anl.gov Wed Aug 10 22:15:26 2011 From: deengert@anl.gov (Douglas E. Engert) Date: Wed, 10 Aug 2011 16:15:26 -0500 Subject: [AFS3-std] AFS3-standardization Co-Chair Nominations time commitments Message-ID: <4E42F4EE.7020807@anl.gov> One of the potential nominees asked: > Can you give me some idea of what time commitment is required? So far it has been only a few hours a week, but depending on how much you want to get involved, and how many drafts are active, it could be more. There are no meeting you have to attend, and the duties of a co-chair are to keep the group inline, and moving. A co-chair could then leave it up to the author of a draft to handle all the issues for a draft or get more involved if this is not happening. (So far that has not been a problem.) The chair does not have to be an expert in the details of a draft, but needs to recognize that others in the group have issues and if there is general consensuses for a draft. After consensuses, we are submitting our drafts as IETF Independent Submissions to the RFC editor. As this process is designed for individuals, not groups, I have left the submission up to the authors. We are breaking ground as a group in submitting a group approved draft in this way. We have our first draft in that state waiting for the three reviewers (they know who they are) to get their reviews in to the RFC Editor. I have had some e-mail discussions with the IETF RFC Editor on this process. on behalf of the group. When the first draft is reviewed, I expect that there will be some additional text that needs to be added to the draft, and to all our drafts. The individual authors of the drafts will have to do this. It is up to the Chair to keep after them. There are two chairs, Hartmut is the co-chair, for one more year, and the new co-chair will have a 2 year term. So it is up to the chairs how the work is split, and how much time you want to put into it. -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From adeason@sinenomine.net Fri Aug 12 17:31:02 2011 From: adeason@sinenomine.net (Andrew Deason) Date: Fri, 12 Aug 2011 11:31:02 -0500 Subject: [AFS3-std] Re: Call for nomination for the position of AFS3-standardization co-chair In-Reply-To: <4E38253A.6000001@anl.gov> References: <4E38253A.6000001@anl.gov> Message-ID: <20110812113102.6efde0c0.adeason@sinenomine.net> I nominate Mike Meffie for co-chair of the AFS3 standardization group. -- Andrew Deason adeason@sinenomine.net From jhutz@cmu.edu Fri Aug 12 22:08:57 2011 From: jhutz@cmu.edu (Jeffrey Hutzelman) Date: Fri, 12 Aug 2011 17:08:57 -0400 Subject: [AFS3-std] Call for nomination for the position of AFS3-standardization co-chair In-Reply-To: <4E429CF4.5060705@secure-endpoints.com> References: <562730635.18.1312985402484.JavaMail.root@thunderbeast.private.linuxbox.com> <4E429CF4.5060705@secure-endpoints.com> Message-ID: <1313183337.3168.275.camel@destiny.pc.cs.cmu.edu> On Wed, 2011-08-10 at 11:00 -0400, Jeffrey Altman wrote: > On 8/10/2011 10:10 AM, Matt W. Benjamin wrote: > > Second. > > > > ----- "Douglas E. Engert" wrote: > > > >> I (as a group member, not as co-chair) would like to place in > >> nomination > >> for the co-chair of the AFS3-standardization group, Jeffrey > >> Hutzelman. > >> > >> Jeff's IETF experiences, knowledge of AFS, and > >> organizations skills make him an ideal candidate for the position. Accept. > I believe that Jeff would make an excellent chair (if he has time) but > would prefer that the Chair not also be a registrar. I'd very much like to take a -- I was going to say "less active", but I really mean more like "less blocking" -- role in the registrar process. We actually have other registrars; perhaps if we can get them truly spun up to the point where they are handling day-to-day requests, such things can actually be handled day-to-day. That said, I don't think there's a strong conflict here; neither chairs nor registrars are intended as a check on the power of the other. -- Jeff From matt@linuxbox.com Sat Aug 13 01:03:09 2011 From: matt@linuxbox.com (Matt W. Benjamin) Date: Fri, 12 Aug 2011 20:03:09 -0400 (EDT) Subject: [AFS3-std] Re: Call for nomination for the position of AFS3-standardization co-chair In-Reply-To: <20110812113102.6efde0c0.adeason@sinenomine.net> Message-ID: <1764277117.94.1313193789600.JavaMail.root@thunderbeast.private.linuxbox.com> Hi, I will second this, I assume it means Mike is a volunteer. Matt ----- "Andrew Deason" wrote: > I nominate Mike Meffie for co-chair of the AFS3 standardization > group. > > -- > Andrew Deason > adeason@sinenomine.net > _______________________________________________ > AFS3-standardization mailing list > AFS3-standardization@openafs.org > http://lists.openafs.org/mailman/listinfo/afs3-standardization -- Matt Benjamin The Linux Box 206 South Fifth Ave. Suite 150 Ann Arbor, MI 48104 http://linuxbox.com tel. 734-761-4689 fax. 734-769-8938 cel. 734-216-5309 From deengert@anl.gov Tue Aug 16 15:09:01 2011 From: deengert@anl.gov (Douglas E. Engert) Date: Tue, 16 Aug 2011 09:09:01 -0500 Subject: [AFS3-std] Fwd: Re: [rfc-ise] AFS3 Standardization and Independent Submissions Message-ID: <4E4A79FD.2000808@anl.gov> Our first draft is moving through the IETF Independent Submission Process= , and is now waiting for the author. As far as I know, the two other reviewers have not sent in their reviews. and it would be good have have all the reviews in before submitting a new= draft. -------- Original Message -------- Subject: Re: [rfc-ise] AFS3 Standardization and Independent Submissions Date: Sat, 13 Aug 2011 17:15:07 -0700 From: Nevil Brownlee Organization: Independent Stream To: Derrick Brashear CC: ISE , Hartmut Reuter , "D= ouglas E. Engert" Hi Derrick: Henry Hotz has sent me the appended review of your draft, so I've changed its state to ISR-AUTH. Would you please consider his comments, and publi= sh a new revision that addresses them. I'm still waiting for reviews from Simon Wilkinson and Jeff Altman, I'll prod them now! Cheers, Nevil On 08/01/2011 06:21 PM, Henry B. Hotz wrote: > I've looked at and it is generally fine per-se as to content. > > What I see as significant problems are historical artifacts of the stan= dardization process. This document updates a protocol that does not have= a pre-existing standard description. Consequently, there are a number o= f things which are referenced, but not defined. > > The biggie is the Rx protocol itself. The standard reference for that = is Ed Zayas' "AFS-3 Programmer=92s Reference: Specification for the Rx Re= mote Procedure Call Facility", Version 1.2 of 28 August 1991. I don't kn= ow if that should be a normative or informative reference. I'm inclined = to say informative since it isn't a standards document and wasn't even re= ally binding on Transarc when they put it out. > > That document appears to define everything which I had marked as needin= g definition when I read the draft. > > The following comments are just nits: > > An informative reference to "AFS-3 Programmer=92s Reference: Architectu= ral Overview" might also be useful, but not necessary. (It's referenced = by the Rx doc anyway.) > > Section 6 makes no mention of how an entity is authenticated. Not sure= it needs to, but I felt funny about it. > > The sentence "It is expected. . ." near the top of page 6 seems unclear= to me. More generally the language concerning how names are to be compa= red stays strictly to what the GSSAPI standards say. Speaking from exper= ience people violate the "MUST NOT" because they need to deal with case-f= olding caused by Microsoft Active Directory. I wish I had some standards= -confoming procedure which also worked with AD without deployment convent= ions or other presumptions, but I don't. Absent such a thing I can't sug= gest (or even ask for) changes, but I could wish for some language that b= etter reflected practical necessity. > > The PrCapabilities line near the top of page 7 should be indented one m= ore level. > > > On Jun 1, 2011, at 7:00 PM, Nevil Brownlee wrote: > >> >> Hi Henry: >> >> It's been about three weeks since you volunteered to review >> the draft: draft-brashear-afs3-pts-extended-names >> >> Can you estimate when you'll be able to send me the review, >> please? >> >> Cheers, Nevil >> >> >> On 9/05/11 12:26 PM, Jeffrey Altman wrote: >>> Nevil: >>> >>> Both Simon and I will do so. >>> >>> Thanks. >>> >>> Jeffrey Altman >>> >>> >>> On 5/8/2011 6:45 PM, Nevil Brownlee wrote: >>>> >>>> Hi Douglas: >>>> >>>> Yes, you've defined 'independent reviewer' correctly. >>>> >>>> Two reviews would be enough, that would be Henry (not involved >>>> in AFS3 efforts) and one other - Simon and Jeff, could you please >>>> decide which of you will do it? (Of course, if you'd both like to, >>>> that would be fine too). >>>> >>>> Here's the note I usually send to prospective reviewers: >>>> >>>> "would you be prepared to do a more detailed review, with two >>>> parts: >>>> a) Comments for the Authors >>>> Reasons for rejection or suggestions for improvements. >>>> These will be returned to authors (or you may wish to have >>>> email discussions directly with authors). Could they also >>>> be published on the Independent Submissions web site, >>>> either as public reviews or as anonymous reviews? >>>> b) Comments for the Independent Submissions Editor >>>> These are advice to the ISE, and will not be published." >>>> >>>> Cheers, Nevil >> >> -- >> Nevil Brownlee (ISE), rfc-ise@rfc-editor.org > > ------------------------------------------------------ > The opinions expressed in this message are mine, > not those of Caltech, JPL, NASA, or the US Government. > Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu > > > --=20 Nevil Brownlee (ISE), rfc-ise@rfc-editor.org From mmeffie@sinenomine.net Tue Aug 16 17:40:41 2011 From: mmeffie@sinenomine.net (Michael Meffie) Date: Tue, 16 Aug 2011 12:40:41 -0400 Subject: [AFS3-std] Re: Call for nomination for the position of AFS3-standardization co-chair In-Reply-To: <1764277117.94.1313193789600.JavaMail.root@thunderbeast.private.linuxbox.com> References: <1764277117.94.1313193789600.JavaMail.root@thunderbeast.private.linuxbox.com> Message-ID: <4E4A9D89.50600@sinenomine.net> Matt W. Benjamin wrote: > Hi, > > I will second this, I assume it means Mike is a volunteer. Yes, thank you. I do accept the nomination. Mike -- From deengert@anl.gov Wed Aug 17 19:55:01 2011 From: deengert@anl.gov (Douglas E. Engert) Date: Wed, 17 Aug 2011 13:55:01 -0500 Subject: Fwd: [AFS3-std] Call for nomination for the position of AFS3-standardization co-chair Message-ID: <4E4C0E85.90908@anl.gov> Today is the day to announce the nominations. But I am having problems getting in touch with our co-chair, Hartmut. The co-chairs have to agree on the nominations, and count the votes. I have not heard from him since March. I have a note into 3 contacts and the secretaries at rzg.mpg.de to see if they know anything. (They may not see the note till tomorrow.) Has anyone heard anything? (It could just be August is vacation time for many of us, and in the future we should consider moving back the elections till a month or two.) -------- Original Message -------- Subject: [AFS3-std] Call for nomination for the position of AFS3-standardization co-chair Date: Tue, 02 Aug 2011 11:26:34 -0500 From: Douglas E. Engert To: afs3-standardization@openafs.org CC: Hartmut Reuter , "Douglas E. Engert" http://tools.ietf.org/id/draft-wilkinson-afs3-standardisation-00.txt defines our election procedures to elect a co-chair. It is my position that is up for election, as I have the one year term. Hartmut Reuter is the other co-chair with the 2 year term, due to expire next year. Schedule: Nominations open 8/2 - 8/16 Announcement of nominations 8/17 Voting 8-17 - 8/31 Election results 9/7 Please read section 2.2.2 as to who can be nominated, and who can vote. Send nominations to Hartmut and myself as the vote takers, and we can contact the potential nominees to make sure they are willing to serve. As Jeff points out: > The subscriber list is not public; however, any subscriber can obtain a > copy by filling in his username and password near the bottom of the page > at https://lists.openafs.org/mailman/listinfo/afs3-standardization and > selecting "Visit Subscriber List". Of course, that's as of today. To > build a voter list, you also need to know that there have been no new > subscribers and no one has unsubscribed since April 25, before the start > of the eligibility period. (You can also get your password sent to you with the "Edit Options") -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 _______________________________________________ AFS3-standardization mailing list AFS3-standardization@openafs.org http://lists.openafs.org/mailman/listinfo/afs3-standardization From jaltman@secure-endpoints.com Thu Aug 18 02:46:45 2011 From: jaltman@secure-endpoints.com (Jeffrey Altman) Date: Wed, 17 Aug 2011 21:46:45 -0400 Subject: [AFS3-std] Re: A call for consensus on draft-deason-afs3-type-time-02 In-Reply-To: <87k4any967.fsf@windlord.stanford.edu> References: <20110728135500.76B9ED@grand.central.org> <4E31776B.1040007@odu.edu> <87ei19yma5.fsf@windlord.stanford.edu> <20110729161932.18bc0ced.adeason@sinenomine.net> <87fwlotw4u.fsf@windlord.stanford.edu> <20110808123258.59cc0539.adeason@sinenomine.net> <8762m7ztbg.fsf@windlord.stanford.edu> <20110808125857.a055922a.adeason@sinenomine.net> <87k4any967.fsf@windlord.stanford.edu> Message-ID: <4E4C6F05.2070701@secure-endpoints.com> This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig960E6E28E0B52C10FA2FA539 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I came across this today which might be of interest: http://data.iers.org/products/16/14844/orig/bulletinc-042.txt Quoting: "IMPORTANT: After years of discussions, a proposal to fundamentally redefine UTC will come to a conclusive vote in January 2012 at the ITU-R in Geneva. "This proposal would halt the intercalary adjustments known as leap seconds that maintain UTC as a form of Universal Time." If the proposal is approved it the definition would change in five years from the vote. Our input will be accepted on the subject until the end of August. There are some interesting papers linked from the questionnaire. http://hpiers.obspm.fr/eop-pc/index.php?index=3Dquestionnaire --------------enig960E6E28E0B52C10FA2FA539 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iQEcBAEBAgAGBQJOTG8IAAoJENxm1CNJffh4YwoH+gLXPdKaRz766xaAh+8gt6J8 sYjHtmMlBr5PWOaPMBi5LUS/QAXTyhZS/EfyxMang48B/ByM44h07nhtXoe+qW9f xk9s0+s3UnPbjpw3+USi9LoeBgAW2x+LVMpL76be9DBM+iTQ2VQT0KrY9cu7Jy+v mGkLWImwfVkGUQczUdvzKNA1oyAm1VdJuYhOFx7meLK3HBmmJL4wSDizb6HiU7Ze s5tp1NLMSctvTJItRSXb9OebXQEEzlSqyVjG1VXOk1GSaGX7sExPZT3fDc//NcV4 GeeiqaUL4eonGcPoKTYn+bBtaXRMZlJKYrUDTolPZ0b4MophVkmr5uA1bmm+GRU= =txEM -----END PGP SIGNATURE----- --------------enig960E6E28E0B52C10FA2FA539-- From reuter@rzg.mpg.de Thu Aug 18 13:26:53 2011 From: reuter@rzg.mpg.de (Hartmut Reuter) Date: Thu, 18 Aug 2011 14:26:53 +0200 Subject: Fwd: [AFS3-std] Call for nomination for the position of AFS3-standardization co-chair In-Reply-To: <4E4C0E85.90908@anl.gov> References: <4E4C0E85.90908@anl.gov> Message-ID: <4E4D050D.2050201@rzg.mpg.de> Douglas E. Engert wrote: > Today is the day to announce the nominations. But I am having > problems getting in touch with our co-chair, Hartmut. The > co-chairs have to agree on the nominations, and count the votes. > > I have not heard from him since March. I have a note into > 3 contacts and the secretaries at rzg.mpg.de to see if > they know anything. (They may not see the note till tomorrow.) > > Has anyone heard anything? > > (It could just be August is vacation time for many of us, and > in the future we should consider moving back the elections > till a month or two.) > Doug, sorry for the delay, I was in holidays without access to my mail, but now I am back. I have now followed the last weeks of the mailing list and it seems to me that there are only three nominations: Kim Kimball Jeffrey Hutzelman Mike Meffie where Kim still hasn't replied to the question if he would accept his nomination. So now we either could follow strictly Simon Wilkinson's proposal and start the voting with two candidates or we could do it less strictly and wait for an answer of Kim before starting the voting. What do you prefer, Doug? I am open for both ways. Hartmut > > -------- Original Message -------- > Subject: [AFS3-std] Call for nomination for the position of > AFS3-standardization co-chair > Date: Tue, 02 Aug 2011 11:26:34 -0500 > From: Douglas E. Engert > To: afs3-standardization@openafs.org > CC: Hartmut Reuter , "Douglas E. Engert" > > > http://tools.ietf.org/id/draft-wilkinson-afs3-standardisation-00.txt > > defines our election procedures to elect a co-chair. It is my position > that is up for election, as I have the one year term. Hartmut Reuter > is the other co-chair with the 2 year term, due to expire next year. > > Schedule: > Nominations open 8/2 - 8/16 > Announcement of nominations 8/17 > Voting 8-17 - 8/31 > Election results 9/7 > > Please read section 2.2.2 as to who can be nominated, and who can vote. > > Send nominations to Hartmut and myself as the vote takers, and we can > contact the potential nominees to make sure they are willing to serve. > > As Jeff points out: >> The subscriber list is not public; however, any subscriber can obtain a >> copy by filling in his username and password near the bottom of the page >> at https://lists.openafs.org/mailman/listinfo/afs3-standardization and >> selecting "Visit Subscriber List". Of course, that's as of today. To >> build a voter list, you also need to know that there have been no new >> subscribers and no one has unsubscribed since April 25, before the start >> of the eligibility period. > > (You can also get your password sent to you with the "Edit Options") > -- ----------------------------------------------------------------- Hartmut Reuter e-mail reuter@rzg.mpg.de phone +49-89-3299-1328 fax +49-89-3299-1301 RZG (Rechenzentrum Garching) web http://www.rzg.mpg.de/~hwr Computing Center of the Max-Planck-Gesellschaft (MPG) and the Institut fuer Plasmaphysik (IPP) ----------------------------------------------------------------- From deengert@anl.gov Thu Aug 18 15:18:24 2011 From: deengert@anl.gov (Douglas E. Engert) Date: Thu, 18 Aug 2011 09:18:24 -0500 Subject: [AFS3-std] Voting for the position of AFS3-standardization co-chair Message-ID: <4E4D1F30.10003@anl.gov> http://tools.ietf.org/id/draft-wilkinson-afs3-standardisation-00.txt defines our election procedures to elect a co-chair for a 2 year term starting October 1. In the option of the co-chairs we have two candidates: Jeffrey Hutzelman Mike Meffie Jeff was nominated by Doug Engert and seconded by Matt W. Benjamin. Mike was nominated by Andrew Deason and seconded by Matt Benjamin. I am revising the schedule so voting starts today, and and on September 1. Schedule: Nominations open 8/2 - 8/16 Announcement of nominations 8/18 * revised Voting 8-18 - 9/1 * revised Election results 9/7 Please read section 2.2.2 as to who can vote. Send votes to Hartmut and myself as the vote takers, *NOT* to the list. Please use the subject of this email for voting, you can reply to it, but *NOT* to the full list. -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 _______________________________________________ AFS3-standardization mailing list AFS3-standardization@openafs.org http://lists.openafs.org/mailman/listinfo/afs3-standardization From simon@sxw.org.uk Thu Aug 18 15:30:02 2011 From: simon@sxw.org.uk (Simon Wilkinson) Date: Thu, 18 Aug 2011 15:30:02 +0100 Subject: [AFS3-std] Voting for the position of AFS3-standardization co-chair In-Reply-To: <4E4D1F30.10003@anl.gov> References: <4E4D1F30.10003@anl.gov> Message-ID: <9CDA9B32-7881-4404-B5B7-CDE86CCF82F8@sxw.org.uk> As an elector, it would help me in casting my vote if the candidates = would be prepared to say something on the list about their vision for = the standardisation process, what time they are prepared to devote to = the job, and how they think we can best move things forwards. Thanks, Simon. From dboyes@sinenomine.net Thu Aug 18 18:20:24 2011 From: dboyes@sinenomine.net (David Boyes) Date: Thu, 18 Aug 2011 12:20:24 -0500 Subject: [AFS3-std] Voting for the position of AFS3-standardization co-chair In-Reply-To: <9CDA9B32-7881-4404-B5B7-CDE86CCF82F8@sxw.org.uk> References: <4E4D1F30.10003@anl.gov> <9CDA9B32-7881-4404-B5B7-CDE86CCF82F8@sxw.org.uk> Message-ID: > As an elector, it would help me in casting my vote if the candidates woul= d be > prepared to say something on the list about their vision for the > standardisation process, what time they are prepared to devote to the job= , > and how they think we can best move things forwards. While an excellent idea, it's not in the process right now. Since we have a= lready started the voting, shouldn't we postpone introducing this until nex= t time (and put this in the charter doc)? -- db From jaltman@secure-endpoints.com Thu Aug 18 18:28:01 2011 From: jaltman@secure-endpoints.com (Jeffrey Altman) Date: Thu, 18 Aug 2011 13:28:01 -0400 Subject: [AFS3-std] Voting for the position of AFS3-standardization co-chair In-Reply-To: References: <4E4D1F30.10003@anl.gov> <9CDA9B32-7881-4404-B5B7-CDE86CCF82F8@sxw.org.uk> Message-ID: <4E4D4BA1.8000809@secure-endpoints.com> This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig8FEAB52BF40AA5AACDC0015E Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 8/18/2011 1:20 PM, David Boyes wrote: >> As an elector, it would help me in casting my vote if the candidates w= ould be >> prepared to say something on the list about their vision for the >> standardisation process, what time they are prepared to devote to the = job, >> and how they think we can best move things forwards. >=20 > While an excellent idea, it's not in the process right now. Since we ha= ve already started the voting, shouldn't we postpone introducing this unt= il next time (and put this in the charter doc)? >=20 > -- db I see no reason why people who are running for an office should feel it within their own powers to communicate with those they are intending to serve. A failure to respond to a request from the community is an indication to me that I shouldn't vote for the unresponsive nominee. It has nothing to do with what is or is not required by the process. Jeffrey Altman --------------enig8FEAB52BF40AA5AACDC0015E Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iQEcBAEBAgAGBQJOTUukAAoJENxm1CNJffh45ngH/3X9SN15SrE6MsBoO2ogdT6x OFHIdXFtOIAC2rHsea1BYBbOfr6e7j//sTvjoTwoQXJDTOa6od2qHy3lh8MI2n/P uaUf/WtsgP9Ad5Hx73oNwSzIUG6IL68j3G/9x1tRUbWgktBUGNo0DKJhvMDB7ZGr F0aQqAyNV8v9gEN8S4i3xjBl1Khk0sJ5ECBZxryUXEsXe/MreVHhntKV7kAe19BW fnjOh0noa1jA1VJYXTT29YrgPBc2lfjM5dNXHmaVefWul3Xi7XY3HSaJvDEQQ1WK FWYIjmlfd1qXjybae1duFODOjQb2Cnr8jvsHBgRhB0xjTXiIrNu2xYYC2swd/yw= =3+Iy -----END PGP SIGNATURE----- --------------enig8FEAB52BF40AA5AACDC0015E-- From dboyes@sinenomine.net Thu Aug 18 18:38:48 2011 From: dboyes@sinenomine.net (David Boyes) Date: Thu, 18 Aug 2011 12:38:48 -0500 Subject: [AFS3-std] Voting for the position of AFS3-standardization co-chair In-Reply-To: <4E4D4BA1.8000809@secure-endpoints.com> References: <4E4D1F30.10003@anl.gov> <9CDA9B32-7881-4404-B5B7-CDE86CCF82F8@sxw.org.uk> <4E4D4BA1.8000809@secure-endpoints.com> Message-ID: PiBBIGZhaWx1cmUgdG8gcmVzcG9uZCB0byBhIHJlcXVlc3QgZnJvbSB0aGUgY29tbXVuaXR5IGlz IGFuIGluZGljYXRpb24gdG8gbWUNCj4gdGhhdCBJIHNob3VsZG4ndCB2b3RlIGZvciB0aGUgdW5y ZXNwb25zaXZlIG5vbWluZWUuICBJdCBoYXMgbm90aGluZyB0byBkbyB3aXRoDQo+IHdoYXQgaXMg b3IgaXMgbm90IHJlcXVpcmVkIGJ5IHRoZSBwcm9jZXNzLg0KDQpJIGRpc2FncmVlLiBXZSdyZSBj aGFuZ2luZyB0aGUgcnVsZXMgbWlkLXN0cmVhbS4gDQoNClJpZ2h0IG5vdywgdGhlcmUgaXMgbm8g cmVxdWlyZW1lbnQgZm9yIGFueW9uZSB0byBwcm92aWRlIGEgc3RhdGVtZW50LiBJZiBzb21lb25l IGRvZXMsIHRoZW4gZ29vZCBmb3IgdGhlbSwgYnV0IHdlIHNob3VsZG4ndCBwZW5hbGl6ZSBwZW9w bGUgZm9yIG5vdCBtYWtpbmcgb25lIGlmIGl0IGlzbid0IHJlcXVpcmVkIGJ5IHRoZSBwcm9jZXNz LiBJdCdzIG5vdCBhIGZhaXIgZXZhbHVhdGlvbiBpZiBldmVyeW9uZSBkb2Vzbid0IGhhdmUgdG8g cGxheSBieSB0aGUgc2FtZSBydWxlcy4gDQpFaXRoZXIgbWFrZSBpdCByZXF1aXJlZCBmb3IgZXZl cnlvbmUsIG9yIGRvbid0IGRvIGl0IChmb3IgdGhpcyB0aW1lKS4gDQoNCi0tIGRiDQoNCg== From adeason@sinenomine.net Thu Aug 18 18:49:03 2011 From: adeason@sinenomine.net (Andrew Deason) Date: Thu, 18 Aug 2011 13:49:03 -0400 Subject: [AFS3-std] Re: Voting for the position of AFS3-standardization co-chair References: <4E4D1F30.10003@anl.gov> <9CDA9B32-7881-4404-B5B7-CDE86CCF82F8@sxw.org.uk> <4E4D4BA1.8000809@secure-endpoints.com> Message-ID: <20110818134903.a314437f.adeason@sinenomine.net> On Thu, 18 Aug 2011 12:38:48 -0500 David Boyes wrote: > > A failure to respond to a request from the community is an > > indication to me that I shouldn't vote for the unresponsive nominee. > > It has nothing to do with what is or is not required by the process. > > I disagree. We're changing the rules mid-stream. > > Right now, there is no requirement for anyone to provide a statement. > If someone does, then good for them, but we shouldn't penalize people > for not making one if it isn't required by the process. The only "penalty" is that Jeff won't vote for them; nowhere do I see that Jeff is suggesting that such candidates would be disqualified or anything like that. Jeff is just expressing a desire as a voter, as far as I can read. It seems good that voters express such opinions, so candidates know what the voters are specifically looking for, if anything. I don't envision myself caring about position statements, but if Jeff does, then... good for him. -- Andrew Deason adeason@sinenomine.net From dboyes@sinenomine.net Thu Aug 18 18:53:43 2011 From: dboyes@sinenomine.net (David Boyes) Date: Thu, 18 Aug 2011 12:53:43 -0500 Subject: [AFS3-std] Re: Voting for the position of AFS3-standardization co-chair In-Reply-To: <20110818134903.a314437f.adeason@sinenomine.net> References: <4E4D1F30.10003@anl.gov> <9CDA9B32-7881-4404-B5B7-CDE86CCF82F8@sxw.org.uk> <4E4D4BA1.8000809@secure-endpoints.com> <20110818134903.a314437f.adeason@sinenomine.net> Message-ID: > The only "penalty" is that Jeff won't vote for them; nowhere do I see tha= t > Jeff is suggesting that such candidates would be disqualified or anything= like > that. Jeff is just expressing a desire as a voter, as far as I can read. Which prima facie gives the people who do supply a statement an advantage i= n that at least one voter will not vote for a candidate that does not suppl= y a statement.=20 > It seems > good that voters express such opinions, so candidates know what the voter= s > are specifically looking for, if anything. Agreed. But then all candidates should supply them.=20 =20 > I don't envision myself caring about position statements, but if Jeff doe= s, > then... good for him. I would like them too. But I want them from all candidates so that I'm comp= aring apples to apples, and that every candidate has an equal probability o= f receiving votes from all the electors.=20 From rra@stanford.edu Thu Aug 18 18:57:07 2011 From: rra@stanford.edu (Russ Allbery) Date: Thu, 18 Aug 2011 10:57:07 -0700 Subject: [AFS3-std] Re: Voting for the position of AFS3-standardization co-chair In-Reply-To: (David Boyes's message of "Thu, 18 Aug 2011 12:53:43 -0500") References: <4E4D1F30.10003@anl.gov> <9CDA9B32-7881-4404-B5B7-CDE86CCF82F8@sxw.org.uk> <4E4D4BA1.8000809@secure-endpoints.com> <20110818134903.a314437f.adeason@sinenomine.net> Message-ID: <87aab6bo24.fsf@windlord.stanford.edu> David Boyes writes: > I would like them too. But I want them from all candidates so that I'm > comparing apples to apples, and that every candidate has an equal > probability of receiving votes from all the electors. You are free to reflect that desire in the way that you vote, in the same way that others are free to reflect their desires for statements in the way that they vote. The rules, so far as I know, don't put any restrictions on what factors influence the votes of the people who are eligible to vote. I suspect we've already exerted more effort arguing about this than it really warranted. -- Russ Allbery (rra@stanford.edu) From adeason@sinenomine.net Thu Aug 18 19:02:23 2011 From: adeason@sinenomine.net (Andrew Deason) Date: Thu, 18 Aug 2011 14:02:23 -0400 Subject: [AFS3-std] Re: Voting for the position of AFS3-standardization co-chair References: <4E4D1F30.10003@anl.gov> <9CDA9B32-7881-4404-B5B7-CDE86CCF82F8@sxw.org.uk> <4E4D4BA1.8000809@secure-endpoints.com> <20110818134903.a314437f.adeason@sinenomine.net> Message-ID: <20110818140223.c5382fd3.adeason@sinenomine.net> On Thu, 18 Aug 2011 12:53:43 -0500 David Boyes wrote: > > I don't envision myself caring about position statements, but if > > Jeff does, then... good for him. > > I would like them too. But I want them from all candidates so that I'm > comparing apples to apples, and that every candidate has an equal > probability of receiving votes from all the electors. I'm not sure what you are suggesting? I think the only request was that everyone does send such a statement. If they don't send one... nothing happens. I'm not sure if you are suggesting that such statements are _required_ (those that don't send one are disqualified), or that nominees _cannot_ send such statements. Both of those sound like rule changes to me moreso than the original requests, but perhaps I am drastically misreading you. If this is just your expression of a voter opinion, then... okay. -- Andrew Deason adeason@sinenomine.net From deengert@anl.gov Thu Aug 18 19:12:13 2011 From: deengert@anl.gov (Douglas E. Engert) Date: Thu, 18 Aug 2011 13:12:13 -0500 Subject: [AFS3-std] Re: Voting for the position of AFS3-standardization co-chair In-Reply-To: <87aab6bo24.fsf@windlord.stanford.edu> References: <4E4D1F30.10003@anl.gov> <9CDA9B32-7881-4404-B5B7-CDE86CCF82F8@sxw.org.uk> <4E4D4BA1.8000809@secure-endpoints.com> <20110818134903.a314437f.adeason@sinenomine.net> <87aab6bo24.fsf@windlord.stanford.edu> Message-ID: <4E4D55FD.8050102@anl.gov> As a co-chair, I see no problem with candidates making statements. On 8/18/2011 12:57 PM, Russ Allbery wrote: > David Boyes writes: > >> I would like them too. But I want them from all candidates so that I'm >> comparing apples to apples, and that every candidate has an equal >> probability of receiving votes from all the electors. > > You are free to reflect that desire in the way that you vote, in the same > way that others are free to reflect their desires for statements in the > way that they vote. The rules, so far as I know, don't put any > restrictions on what factors influence the votes of the people who are > eligible to vote. > > I suspect we've already exerted more effort arguing about this than it > really warranted. > -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From dboyes@sinenomine.net Thu Aug 18 19:15:35 2011 From: dboyes@sinenomine.net (David Boyes) Date: Thu, 18 Aug 2011 13:15:35 -0500 Subject: [AFS3-std] Re: Voting for the position of AFS3-standardization co-chair In-Reply-To: <20110818140223.c5382fd3.adeason@sinenomine.net> References: <4E4D1F30.10003@anl.gov> <9CDA9B32-7881-4404-B5B7-CDE86CCF82F8@sxw.org.uk> <4E4D4BA1.8000809@secure-endpoints.com> <20110818134903.a314437f.adeason@sinenomine.net> <20110818140223.c5382fd3.adeason@sinenomine.net> Message-ID: > I'm not sure what you are suggesting? I am suggesting that in the future, the process be changed to require a sta= tement like the one Simon requested from all candidates. I am also suggesti= ng that while it would be nice to have that for this election voluntarily, = not having it should not be a valid basis for rejecting a candidate for the= current election, since the request occurred after the official start of t= he voting period.=20 I don't have any problem with someone providing a statement. I do have a pr= oblem with people stating that they will reject out of hand a candidate tha= t does not provide one if the request was not present at the start of votin= g.=20 > I'm not sure if you are suggesting that such statements are _required_ > (those that don't send one are disqualified), or that nominees _cannot_ s= end > such statements. Both of those sound like rule changes to me moreso than > the original requests, but perhaps I am drastically misreading you. See above. I would like to see evidence that a candidate has thought about = the long-term process and what they intend to do as chair.=20 From mmeffie@sinenomine.net Thu Aug 18 19:36:59 2011 From: mmeffie@sinenomine.net (Michael Meffie) Date: Thu, 18 Aug 2011 14:36:59 -0400 Subject: [AFS3-std] Voting for the position of AFS3-standardization co-chair In-Reply-To: <9CDA9B32-7881-4404-B5B7-CDE86CCF82F8@sxw.org.uk> References: <4E4D1F30.10003@anl.gov> <9CDA9B32-7881-4404-B5B7-CDE86CCF82F8@sxw.org.uk> Message-ID: <4E4D5BCB.9070604@sinenomine.net> Simon Wilkinson wrote: > As an elector, it would help me in casting my vote if the candidates > would be prepared to say something on the list about their vision for > the standardisation process, what time they are prepared to devote to > the job, and how they think we can best move things forwards. I agree it is a reasonable request, Simon. If I had the opporunity to co-chair the group, firstly I would do my best to provide to the group regular, periodic updates of the work in progress, the status of work in progress, and public and private reminders as needed. I would like to include timelines which should show where we stand on documents to ensure we are moving forward in a timely fashion. I have participated in industry-standard forums in the past, although not related to IETF, and understand the issues of fairness and cooperation which is required to build a consensus. In terms of time, I understand this position will require some time per work week and would be able to dedicate time each week to facilitate the standardization process. Mike -- From gary.buhrmaster@gmail.com Fri Aug 19 07:54:44 2011 From: gary.buhrmaster@gmail.com (Gary Buhrmaster) Date: Thu, 18 Aug 2011 23:54:44 -0700 Subject: [AFS3-std] Re: Voting for the position of AFS3-standardization co-chair In-Reply-To: References: <4E4D1F30.10003@anl.gov> <9CDA9B32-7881-4404-B5B7-CDE86CCF82F8@sxw.org.uk> <4E4D4BA1.8000809@secure-endpoints.com> <20110818134903.a314437f.adeason@sinenomine.net> <20110818140223.c5382fd3.adeason@sinenomine.net> Message-ID: On Thu, Aug 18, 2011 at 11:15, David Boyes wrote: .. > I am suggesting that in the future, the process be changed to require a statement like the one Simon requested from all candidates. In the more formal elections I am familiar with, candidates have the option of offering a statement or to choose to provide none at all. I think that is the appropriate way forward (and the voters will make of those choices by the candidates what they will, as it should be). One alternative might be a (built-in) hold between the candidates being announced and voting beginning to allow the candidates to state their positions on list. Another might be that the chairs ask that as part of the acceptance of the nomination the potential candidate is offered an opportunity to provide a statement that the chair would include in the formal "election has started" email. But that would be for the next election. This election is already in progress. From dboyes@sinenomine.net Fri Aug 19 08:28:58 2011 From: dboyes@sinenomine.net (David Boyes) Date: Fri, 19 Aug 2011 02:28:58 -0500 Subject: [AFS3-std] Re: Voting for the position of AFS3-standardization co-chair In-Reply-To: References: <4E4D1F30.10003@anl.gov> <9CDA9B32-7881-4404-B5B7-CDE86CCF82F8@sxw.org.uk> <4E4D4BA1.8000809@secure-endpoints.com> <20110818134903.a314437f.adeason@sinenomine.net> <20110818140223.c5382fd3.adeason@sinenomine.net> Message-ID: <35BBE9DA-E253-4A01-A02A-B437E3EE6311@sinenomine.net> > One alternative might be a (built-in) hold between > the candidates being announced and voting beginning > to allow the candidates to state their positions on list. > Another might be that the chairs ask that as part > of the acceptance of the nomination the potential > candidate is offered an opportunity to provide a > statement that the chair would include in the > formal "election has started" email. Either of these options seem reasonable for next time. I do still think tha= t if we use them, we should officially add them to the process.= From adeason@sinenomine.net Fri Aug 26 23:29:32 2011 From: adeason@sinenomine.net (Andrew Deason) Date: Fri, 26 Aug 2011 17:29:32 -0500 Subject: [AFS3-std] New version of the 64-bit time I-D (-03) Message-ID: <20110826172932.c2ec883f.adeason@sinenomine.net> draft-deason-afs3-type-time-03 has been posted and is available at This changes the epoch of the absolute time types to the Unix epoch, and changes the names to include '64' in them. Some discussion about differing time granularities and pre-UTC dates has been added. There are a lot of changes between -02 and -03, most of which are just to accommodate the changes in epoch and type names, and other minor stuff like that. While I appreciate feedback on anything in the document, sections 5 (Resolution Limitations) and 6 (Times Before UTC) are completely new, and contain more substantive new text than any other changes. So, if you don't want to read the whole thing again, I'd urge you to at least read those two sections. -- Andrew Deason adeason@sinenomine.net From deengert@anl.gov Mon Aug 29 14:24:53 2011 From: deengert@anl.gov (Douglas E. Engert) Date: Mon, 29 Aug 2011 08:24:53 -0500 Subject: Fwd: [AFS3-std] Voting for the position of AFS3-standardization co-chair Message-ID: <4E5B9325.9020507@anl.gov> This is a reminder, your votes must be in by the end of Thursday 9/1. -------- Original Message -------- Subject: [AFS3-std] Voting for the position of AFS3-standardization co-chair Date: Thu, 18 Aug 2011 09:18:24 -0500 From: Douglas E. Engert To: afs3-standardization@openafs.org CC: Hartmut Reuter , "Douglas E. Engert" http://tools.ietf.org/id/draft-wilkinson-afs3-standardisation-00.txt defines our election procedures to elect a co-chair for a 2 year term starting October 1. In the option of the co-chairs we have two candidates: Jeffrey Hutzelman Mike Meffie Jeff was nominated by Doug Engert and seconded by Matt W. Benjamin. Mike was nominated by Andrew Deason and seconded by Matt Benjamin. I am revising the schedule so voting starts today, and and on September 1. Schedule: Nominations open 8/2 - 8/16 Announcement of nominations 8/18 * revised Voting 8-18 - 9/1 * revised Election results 9/7 Please read section 2.2.2 as to who can vote. Send votes to Hartmut and myself as the vote takers, *NOT* to the list. Please use the subject of this email for voting, you can reply to it, but *NOT* to the full list. -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 _______________________________________________ AFS3-standardization mailing list AFS3-standardization@openafs.org http://lists.openafs.org/mailman/listinfo/afs3-standardization _______________________________________________ AFS3-standardization mailing list AFS3-standardization@openafs.org http://lists.openafs.org/mailman/listinfo/afs3-standardization From deengert@anl.gov Wed Aug 31 21:21:44 2011 From: deengert@anl.gov (Douglas E. Engert) Date: Wed, 31 Aug 2011 15:21:44 -0500 Subject: Fwd: [AFS3-std] Voting for the position of AFS3-standardization co-chair Message-ID: <4E5E97D8.3060204@anl.gov> This is a reminder, you have only one more day to vote. Votes must be received by Thu, 01 Sep 2011 23:59:59 -0500 (CDT) Last year 21 people voted, so far we have received only 10 votes. -------- Original Message -------- Subject: [AFS3-std] Voting for the position of AFS3-standardization co-chair Date: Thu, 18 Aug 2011 09:18:24 -0500 From: Douglas E. Engert To: afs3-standardization@openafs.org CC: Hartmut Reuter , "Douglas E. Engert" http://tools.ietf.org/id/draft-wilkinson-afs3-standardisation-00.txt defines our election procedures to elect a co-chair for a 2 year term starting October 1. In the option of the co-chairs we have two candidates: Jeffrey Hutzelman Mike Meffie Jeff was nominated by Doug Engert and seconded by Matt W. Benjamin. Mike was nominated by Andrew Deason and seconded by Matt Benjamin. I am revising the schedule so voting starts today, and and on September 1. Schedule: Nominations open 8/2 - 8/16 Announcement of nominations 8/18 * revised Voting 8-18 - 9/1 * revised Election results 9/7 Please read section 2.2.2 as to who can vote. Send votes to Hartmut and myself as the vote takers, *NOT* to the list. Please use the subject of this email for voting, you can reply to it, but *NOT* to the full list. -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 _______________________________________________ AFS3-standardization mailing list AFS3-standardization@openafs.org http://lists.openafs.org/mailman/listinfo/afs3-standardization _______________________________________________ AFS3-standardization mailing list AFS3-standardization@openafs.org http://lists.openafs.org/mailman/listinfo/afs3-standardization _______________________________________________ AFS3-standardization mailing list AFS3-standardization@openafs.org http://lists.openafs.org/mailman/listinfo/afs3-standardization From tkeiser@sinenomine.net Mon Aug 1 00:53:40 2011 From: tkeiser@sinenomine.net (Tom Keiser) Date: Sun, 31 Jul 2011 19:53:40 -0400 Subject: [AFS3-std] Re: XDR extensible union type In-Reply-To: <5D0108C15137EC449A517DD8454DE71503041C69F4@34093-MBX-C15.mex07a.mlsrvr.com> References: <5D0108C15137EC449A517DD8454DE71503041C69F4@34093-MBX-C15.mex07a.mlsrvr.com> Message-ID: --0015174483e85c0ec004a9663966 Content-Type: text/plain; charset=ISO-8859-1 I pushed draft-keiser-afs3-xdr-union-03 (incorporating Derrick's grammatical corrections) to the IETF last week. Comments are hereby solicited. http://tools.ietf.org/html/draft-keiser-afs3-xdr-union-03 Cheers, -Tom On Jul 20, 2011 8:46 PM, "Tom Keiser" wrote: > Hi Derrick, > > Thanks very much for the review; I'll incorporate those edits. > > I'd like to publish -03 on Tuesday. If any interested party can find time to send comments by Monday, it would be greatly appreciated. > > Cheers, > > -Tom > > Sent from my phone; please excuse any typographic or grammatical errors. > > -----Original Message----- > From: Derrick Brashear [shadow@gmail.com] > Received: Wednesday, 20 Jul 2011, 9:33am > To: Tom Keiser [tkeiser@sinenomine.net] > Subject: Re: [AFS3-std] Re: XDR extensible union type > > i lie > > "1. Lookup the discriminant" > > I believe that should be, as an operation, "look up" > > > On Wed, Jul 20, 2011 at 9:31 AM, Derrick Brashear wrote: >> 6. AFS Assign Numbers Registrar Considerations >> >> "Assigned" >> >> the actual content is fine and i see no issues. >> >> On Tue, Jul 19, 2011 at 6:02 PM, Tom Keiser wrote: >>> On Jun 20, 2011 2:41 PM, "Tom Keiser" wrote: >>>> Hi all, >>>> >>>> I pushed a new revision of draft-keiser-afs3-xdr-union: >>>> >>>> http://tools.ietf.org/html/draft-keiser-afs3-xdr-union-02 >>>> >>>> This revision incorporates the following two changes: >>>> >>>> * modify section on error handling (3.4.1) to make length mismatches a >>>> fatal error >>>> * add a "use case" section (1.1) to discuss trade-offs associated with >>>> using this type >>>> >>>> Any comments are welcome. >>>> >>>> -Tom >>> >>> This is a second call for review of draft-keiser-afs3-xdr-union-02; all >>> comments are welcome. >>> >>> Cheers, >>> >>> -Tom >> >> >> >> -- >> Derrick >> > > > > -- > Derrick --0015174483e85c0ec004a9663966 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

I pushed draft-keiser-afs3-xdr-union-03 (incorporating Derrick's gra= mmatical corrections) to the IETF last week.=A0 Comments are hereby solicit= ed.

ht= tp://tools.ietf.org/html/draft-keiser-afs3-xdr-union-03

Cheers,

-Tom

On Jul 20, 2011 8:46 PM, "Tom Keiser" = <tkeiser@sinenomine.net>= ; wrote:
> Hi Derrick,
>
> Thanks v= ery much for the review; I'll incorporate those edits.
>
> I'd like to publish -03 on Tuesday. If any interested par= ty can find time to send comments by Monday, it would be greatly appreciate= d.
>
> Cheers,
>
> -Tom
>
> Sent fro= m my phone; please excuse any typographic or grammatical errors.
>
> -----Original Message-----
> From: Derrick Brashear [shadow@gmail.com]
> Received: W= ednesday, 20 Jul 2011, 9:33am
> To: Tom Keiser [tkeiser@sinenomine.net]
> Subject: Re: [AFS3-std] Re: XDR extensible union type
>
>= i lie
>
> "1. Lookup the discriminant"
> > I believe that should be, as an operation, "look up"
>
>
> On Wed, Jul 20, 2011 at 9:31 AM, Derrick Brashear &l= t;shadow@gmail.com> wrote:
&g= t;> 6. AFS Assign Numbers Registrar Considerations
>>
>&= gt; "Assigned"
>>
>> the actual content is fine and i see no issues.
>= ;>
>> On Tue, Jul 19, 2011 at 6:02 PM, Tom Keiser <tkeiser@sinenomine.net> wrote: >>> On Jun 20, 2011 2:41 PM, "Tom Keiser" <tkeiser@sinenomine.net> wrote:
&g= t;>>> Hi all,
>>>>
>>>> I pushed a n= ew revision of draft-keiser-afs3-xdr-union:
>>>>
>>>> http://tools.ietf.org/html/draft-keiser-afs= 3-xdr-union-02
>>>>
>>>> This revision in= corporates the following two changes:
>>>>
>>>> * modify section on error handling (3.= 4.1) to make length mismatches a
>>>> fatal error
>>= ;>> * add a "use case" section (1.1) to discuss trade-offs = associated with
>>>> using this type
>>>>
>>>> An= y comments are welcome.
>>>>
>>>> -Tom
>= ;>>
>>> This is a second call for review of draft-keiser= -afs3-xdr-union-02; all
>>> comments are welcome.
>>>
>>> Cheers,<= br>>>>
>>> -Tom
>>
>>
>>>> --
>> Derrick
>>
>
>
>
> --
> Derrick
--0015174483e85c0ec004a9663966-- From simon@sxw.org.uk Mon Aug 1 18:07:35 2011 From: simon@sxw.org.uk (Simon Wilkinson) Date: Mon, 1 Aug 2011 18:07:35 +0100 Subject: [AFS3-std] Re: A call for consensus on draft-deason-afs3-type-time-02 In-Reply-To: <87fwlotw4u.fsf@windlord.stanford.edu> References: <20110728135500.76B9ED@grand.central.org> <4E31776B.1040007@odu.edu> <87ei19yma5.fsf@windlord.stanford.edu> <20110729161932.18bc0ced.adeason@sinenomine.net> <87fwlotw4u.fsf@windlord.stanford.edu> Message-ID: Given how much of what we want to do depends on defining a new time type, it= would be good to keep up the momentum with this draft. Would those with problems with the current draft be prepared to suggest new w= ording for: a) the epoch value b) the granularity that we could use as a basis for further discussion? It would also be wonder= ful if everyone with an interest in this topic could participate in that dis= cussion, rather than waiting for another last call to raise objections. Thanks, Simon= From rra@stanford.edu Mon Aug 1 18:13:57 2011 From: rra@stanford.edu (Russ Allbery) Date: Mon, 01 Aug 2011 10:13:57 -0700 Subject: [AFS3-std] Re: A call for consensus on draft-deason-afs3-type-time-02 In-Reply-To: (Simon Wilkinson's message of "Mon, 1 Aug 2011 18:07:35 +0100") References: <20110728135500.76B9ED@grand.central.org> <4E31776B.1040007@odu.edu> <87ei19yma5.fsf@windlord.stanford.edu> <20110729161932.18bc0ced.adeason@sinenomine.net> <87fwlotw4u.fsf@windlord.stanford.edu> Message-ID: <87wrex836y.fsf@windlord.stanford.edu> Simon Wilkinson writes: > Would those with problems with the current draft be prepared to suggest > new wording for: > a) the epoch value > b) the granularity > that we could use as a basis for further discussion? It would also be > wonderful if everyone with an interest in this topic could participate > in that discussion, rather than waiting for another last call to raise > objections. As nice as it would be to be able to represent old timestamps in the file system, we've never been able to before (at least consistently), and I think the simplicity benefits for compatibility with current code bases of sticking with the POSIX epoch are substantial. I don't have an opinion on the granularity. For me, the benefits of matching NFS and the POSIX timestamp granularity is fairly evenly balanced against the drawbacks of increasing the size of all of our protocol packets. -- Russ Allbery (rra@stanford.edu) From matt@linuxbox.com Mon Aug 1 18:21:47 2011 From: matt@linuxbox.com (Matt W. Benjamin) Date: Mon, 1 Aug 2011 13:21:47 -0400 (EDT) Subject: [AFS3-std] Re: A call for consensus on draft-deason-afs3-type-time-02 In-Reply-To: <87wrex836y.fsf@windlord.stanford.edu> Message-ID: <159746358.62.1312219307195.JavaMail.root@thunderbeast.private.linuxbox.com> Hi, a) with Russ b) Intuitively I would have voted and would vote for the more NFS, POSIX flavor of timestamp granularity. In prior discussion, that was not the consensus. Matt ----- "Russ Allbery" wrote: > Simon Wilkinson writes: > > > Would those with problems with the current draft be prepared to > suggest > > new wording for: > > > a) the epoch value > > b) the granularity > > As nice as it would be to be able to represent old timestamps in the > file > system, we've never been able to before (at least consistently), and > I > think the simplicity benefits for compatibility with current code > bases of > sticking with the POSIX epoch are substantial. > > I don't have an opinion on the granularity. For me, the benefits of > matching NFS and the POSIX timestamp granularity is fairly evenly > balanced > against the drawbacks of increasing the size of all of our protocol > packets. > -- Matt Benjamin The Linux Box 206 South Fifth Ave. Suite 150 Ann Arbor, MI 48104 http://linuxbox.com tel. 734-761-4689 fax. 734-769-8938 cel. 734-216-5309 From adeason@sinenomine.net Mon Aug 1 18:28:10 2011 From: adeason@sinenomine.net (Andrew Deason) Date: Mon, 1 Aug 2011 12:28:10 -0500 Subject: [AFS3-std] Re: A call for consensus on draft-deason-afs3-type-time-02 References: <20110728135500.76B9ED@grand.central.org> <4E31776B.1040007@odu.edu> <87ei19yma5.fsf@windlord.stanford.edu> <20110729161932.18bc0ced.adeason@sinenomine.net> <87fwlotw4u.fsf@windlord.stanford.edu> Message-ID: <20110801122810.81b1889c.adeason@sinenomine.net> On Mon, 1 Aug 2011 18:07:35 +0100 Simon Wilkinson wrote: > Given how much of what we want to do depends on defining a new time > type, it would be good to keep up the momentum with this draft. > > Would those with problems with the current draft be prepared to > suggest new wording for: > > a) the epoch value I don't think I've heard any significant arguments for keeping the epoch as it exists in the current draft. And since there are issues with the current epoch value that Russ has detailed, it makes sense to me to change it to the posix epoch. I was going to change it unless I heard someone object; I'll propose some new text soon based on Russ' suggestions unless someone else wants to. > b) the granularity This one I still have no idea on. I see reasons for both sides. > that we could use as a basis for further discussion? It would also be > wonderful if everyone with an interest in this topic could participate > in that discussion, rather than waiting for another last call to raise > objections. Most people involved have a lot of deadlines to work with and balance. Right now, the only "deadline" we are given for standards discussion is the last call. If you want to ensure discussion before that point, give another deadline. -- Andrew Deason adeason@sinenomine.net From shadow@gmail.com Mon Aug 1 18:32:46 2011 From: shadow@gmail.com (Derrick Brashear) Date: Mon, 1 Aug 2011 13:32:46 -0400 Subject: [AFS3-std] Re: A call for consensus on draft-deason-afs3-type-time-02 In-Reply-To: <20110801122810.81b1889c.adeason@sinenomine.net> References: <20110728135500.76B9ED@grand.central.org> <4E31776B.1040007@odu.edu> <87ei19yma5.fsf@windlord.stanford.edu> <20110729161932.18bc0ced.adeason@sinenomine.net> <87fwlotw4u.fsf@windlord.stanford.edu> <20110801122810.81b1889c.adeason@sinenomine.net> Message-ID: On Mon, Aug 1, 2011 at 1:28 PM, Andrew Deason wrote: >> b) the granularity > > This one I still have no idea on. I see reasons for both sides. So is there a reason an extended union with the various stamp granularities would be a nonstarter? In particular I'd suggest the draft strongly discourage sending a larger timestamp than actual information supports (e.g. don't use bits to send precision you don't have, rather than trailing-zero-padding a larger than needed number) -- Derrick From jaltman@secure-endpoints.com Mon Aug 1 18:39:35 2011 From: jaltman@secure-endpoints.com (Jeffrey Altman) Date: Mon, 01 Aug 2011 13:39:35 -0400 Subject: [AFS3-std] Re: A call for consensus on draft-deason-afs3-type-time-02 In-Reply-To: <87wrex836y.fsf@windlord.stanford.edu> References: <20110728135500.76B9ED@grand.central.org> <4E31776B.1040007@odu.edu> <87ei19yma5.fsf@windlord.stanford.edu> <20110729161932.18bc0ced.adeason@sinenomine.net> <87fwlotw4u.fsf@windlord.stanford.edu> <87wrex836y.fsf@windlord.stanford.edu> Message-ID: <4E36E4D7.9010308@secure-endpoints.com> This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig4A27C580FE23C3E7E55C905E Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 8/1/2011 1:13 PM, Russ Allbery wrote: > As nice as it would be to be able to represent old timestamps in the fi= le > system, we've never been able to before (at least consistently), and I > think the simplicity benefits for compatibility with current code bases= of > sticking with the POSIX epoch are substantial. > > I don't have an opinion on the granularity. For me, the benefits of > matching NFS and the POSIX timestamp granularity is fairly evenly balan= ced > against the drawbacks of increasing the size of all of our protocol > packets. I have a strong desire to ensure that everything that can be represented in an NTFS file system can be represented in AFS. I don't care if the epoch is the same or if the granularity is better than 100ns or not. I am concerned about the size of status structures given how frequently they are sent and because the size of the status structure determines how many FIDs can be specified in a single Bulk Status request. It would be nice if we could have some form of compressed time representation that only sent the required number of bits necessary to represent the required granularity. Jeffrey Altman --------------enig4A27C580FE23C3E7E55C905E Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iQEcBAEBAgAGBQJONuTdAAoJENxm1CNJffh4/1EH/2edEyuNmABtPOma63yPvItC dlmgGYHO5YnJyW7dsoPyE4+wtorPCPFpVIriwIyke7eXhBjDHYod0sE+PjMa00US elGszsC+O8YFReJQkvCUo6K82sTNmjIDI95tFtTWPuPM4NDniN7HW2IhjqbIZOX1 pArwMylZD2BUk+GjPbpElgWqQoFhB96pHgmS4UK94brY9wGfjo/geMWgN/kLm5OP pGtiAhj01mDrr5qKYe8l0fQm9EVd2BTB2TI7flshB5foFFx+86LadxQdyhUciDdg W6NHvqbEbDPoHvOqsrHg4bvxYQnsXBkDGsnC2goeZ3B1pMKt466GHoUbBtEAXXU= =EWEN -----END PGP SIGNATURE----- --------------enig4A27C580FE23C3E7E55C905E-- From rra@stanford.edu Mon Aug 1 18:50:51 2011 From: rra@stanford.edu (Russ Allbery) Date: Mon, 01 Aug 2011 10:50:51 -0700 Subject: [AFS3-std] Re: A call for consensus on draft-deason-afs3-type-time-02 In-Reply-To: <4E36E4D7.9010308@secure-endpoints.com> (Jeffrey Altman's message of "Mon, 01 Aug 2011 13:39:35 -0400") References: <20110728135500.76B9ED@grand.central.org> <4E31776B.1040007@odu.edu> <87ei19yma5.fsf@windlord.stanford.edu> <20110729161932.18bc0ced.adeason@sinenomine.net> <87fwlotw4u.fsf@windlord.stanford.edu> <87wrex836y.fsf@windlord.stanford.edu> <4E36E4D7.9010308@secure-endpoints.com> Message-ID: <87fwll81hg.fsf@windlord.stanford.edu> Jeffrey Altman writes: > I have a strong desire to ensure that everything that can be represented > in an NTFS file system can be represented in AFS. Does that include timestamps prior to 1970, just to check? -- Russ Allbery (rra@stanford.edu) From adeason@sinenomine.net Mon Aug 1 18:53:44 2011 From: adeason@sinenomine.net (Andrew Deason) Date: Mon, 1 Aug 2011 12:53:44 -0500 Subject: [AFS3-std] Re: A call for consensus on draft-deason-afs3-type-time-02 References: <20110728135500.76B9ED@grand.central.org> <4E31776B.1040007@odu.edu> <87ei19yma5.fsf@windlord.stanford.edu> <20110729161932.18bc0ced.adeason@sinenomine.net> <87fwlotw4u.fsf@windlord.stanford.edu> <20110801122810.81b1889c.adeason@sinenomine.net> Message-ID: <20110801125344.e9e45873.adeason@sinenomine.net> On Mon, 1 Aug 2011 13:32:46 -0400 Derrick Brashear wrote: > On Mon, Aug 1, 2011 at 1:28 PM, Andrew Deason wrote: > > >> b) the granularity > > > > This one I still have no idea on. I see reasons for both sides. > > So is there a reason an extended union with the various stamp > granularities would be a nonstarter? In particular I'd suggest the > draft strongly discourage > sending a larger timestamp than actual information supports (e.g. > don't use bits to send precision you don't have, rather than > trailing-zero-padding a > larger than needed number) Well, the objection to just having 64-bit seconds and 32-bit nanoseconds is "space", and a union tag is an extra 32 bits... If we had a "100 NS granularity" tag, then we'd have 100-ns granularity in 96 bits, whereas now we could have 1-ns granularity in 96 bits. Unless there's some other scheme you're thinking of that somehow makes this more efficient? I had some kind of variable-length scheme that encoded the granularity in the 'unused' bits of the value for coarser granularities, but I'm pretty sure that only saved space for the *TimeRes types, and doesn't really help for 'plain' times. -- Andrew Deason adeason@sinenomine.net From jaltman@secure-endpoints.com Mon Aug 1 19:01:25 2011 From: jaltman@secure-endpoints.com (Jeffrey Altman) Date: Mon, 01 Aug 2011 14:01:25 -0400 Subject: [AFS3-std] Re: A call for consensus on draft-deason-afs3-type-time-02 In-Reply-To: <87fwll81hg.fsf@windlord.stanford.edu> References: <20110728135500.76B9ED@grand.central.org> <4E31776B.1040007@odu.edu> <87ei19yma5.fsf@windlord.stanford.edu> <20110729161932.18bc0ced.adeason@sinenomine.net> <87fwlotw4u.fsf@windlord.stanford.edu> <87wrex836y.fsf@windlord.stanford.edu> <4E36E4D7.9010308@secure-endpoints.com> <87fwll81hg.fsf@windlord.stanford.edu> Message-ID: <4E36E9F5.9000502@secure-endpoints.com> This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig23F50A5B2A28DAF581F3533F Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 8/1/2011 1:50 PM, Russ Allbery wrote: > Jeffrey Altman writes: >=20 >> I have a strong desire to ensure that everything that can be represent= ed >> in an NTFS file system can be represented in AFS. >=20 > Does that include timestamps prior to 1970, just to check? >=20 Yes. --------------enig23F50A5B2A28DAF581F3533F Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iQEcBAEBAgAGBQJONun2AAoJENxm1CNJffh4mrIIAIEPpQF6ZniJKtOR3Go0RhOo UJihNKxv52kCD9Jsulu+C19n5L0QkqfFqXUSJNtOqU0a7M0rypzhiyOmpdKiboiB st2NhCi50BPkbVq68+GbhzHIZLNEs3aMnV8Xhhl76e9s+rmlXy7G/bY1pMxIWYAn zY58jFCcgeeTHf06qcGsop1VwyQX4Vy/POnbs5+YybtOxTGIvi/awa2YFaqLZeyz pUZe8TgpYR3XODPoc6ykc/SFoD4c+PpToHEXQFHZVWbpDpMIU9M4WmbZESRGObxX 5bqOusZgx7THzk5r5nTc8BWWmp5tnPvALz+MOlHTRvFje99rwQz/Cl+luWDY/ak= =Tflf -----END PGP SIGNATURE----- --------------enig23F50A5B2A28DAF581F3533F-- From rra@stanford.edu Mon Aug 1 19:13:50 2011 From: rra@stanford.edu (Russ Allbery) Date: Mon, 01 Aug 2011 11:13:50 -0700 Subject: [AFS3-std] Re: A call for consensus on draft-deason-afs3-type-time-02 In-Reply-To: <4E36E9F5.9000502@secure-endpoints.com> (Jeffrey Altman's message of "Mon, 01 Aug 2011 14:01:25 -0400") References: <20110728135500.76B9ED@grand.central.org> <4E31776B.1040007@odu.edu> <87ei19yma5.fsf@windlord.stanford.edu> <20110729161932.18bc0ced.adeason@sinenomine.net> <87fwlotw4u.fsf@windlord.stanford.edu> <87wrex836y.fsf@windlord.stanford.edu> <4E36E4D7.9010308@secure-endpoints.com> <87fwll81hg.fsf@windlord.stanford.edu> <4E36E9F5.9000502@secure-endpoints.com> Message-ID: <871ux580f5.fsf@windlord.stanford.edu> Jeffrey Altman writes: > On 8/1/2011 1:50 PM, Russ Allbery wrote: >> Jeffrey Altman writes: >>> I have a strong desire to ensure that everything that can be represented >>> in an NTFS file system can be represented in AFS. >> Does that include timestamps prior to 1970, just to check? > Yes. Okay, so you *do* care about what epoch is used, unless we use a time definition that allows for negative offsets from the epoch. Does Microsoft have documentation for how the Windows epoch deals with Gregorian calendar conversions and leap seconds? -- Russ Allbery (rra@stanford.edu) From shadow@gmail.com Mon Aug 1 19:19:11 2011 From: shadow@gmail.com (Derrick Brashear) Date: Mon, 1 Aug 2011 14:19:11 -0400 Subject: [AFS3-std] Re: A call for consensus on draft-deason-afs3-type-time-02 In-Reply-To: <20110801125344.e9e45873.adeason@sinenomine.net> References: <20110728135500.76B9ED@grand.central.org> <4E31776B.1040007@odu.edu> <87ei19yma5.fsf@windlord.stanford.edu> <20110729161932.18bc0ced.adeason@sinenomine.net> <87fwlotw4u.fsf@windlord.stanford.edu> <20110801122810.81b1889c.adeason@sinenomine.net> <20110801125344.e9e45873.adeason@sinenomine.net> Message-ID: On Mon, Aug 1, 2011 at 1:53 PM, Andrew Deason wrote: > On Mon, 1 Aug 2011 13:32:46 -0400 > Derrick Brashear wrote: > >> On Mon, Aug 1, 2011 at 1:28 PM, Andrew Deason wrote: >> >> >> b) the granularity >> > >> > This one I still have no idea on. I see reasons for both sides. >> >> So is there a reason an extended union with the various stamp >> granularities would be a nonstarter? In particular I'd suggest the >> draft strongly discourage >> sending a larger timestamp than actual information supports (e.g. >> don't use bits to send precision you don't have, rather than >> trailing-zero-padding a >> larger than needed number) > > Well, the objection to just having 64-bit seconds and 32-bit nanoseconds > is "space", and a union tag is an extra 32 bits... If we had a "100 NS > granularity" tag, then we'd have 100-ns granularity in 96 bits, whereas > now we could have 1-ns granularity in 96 bits. Unless there's some other > scheme you're thinking of that somehow makes this more efficient? for the worst case, it's worse. for the best case, it's better. but i suppose it may not be worth it given that the worst case will become more prevalent over time. > I had some kind of variable-length scheme that encoded the granularity > in the 'unused' bits of the value for coarser granularities, but I'm > pretty sure that only saved space for the *TimeRes types, and doesn't > really help for 'plain' times. and those are going to be a majority, i think. -- Derrick From tkeiser@sinenomine.net Mon Aug 1 21:16:44 2011 From: tkeiser@sinenomine.net (Tom Keiser) Date: Mon, 1 Aug 2011 16:16:44 -0400 Subject: [AFS3-std] Re: A call for consensus on draft-deason-afs3-type-time-02 In-Reply-To: <20110801125344.e9e45873.adeason@sinenomine.net> References: <20110728135500.76B9ED@grand.central.org> <4E31776B.1040007@odu.edu> <87ei19yma5.fsf@windlord.stanford.edu> <20110729161932.18bc0ced.adeason@sinenomine.net> <87fwlotw4u.fsf@windlord.stanford.edu> <20110801122810.81b1889c.adeason@sinenomine.net> <20110801125344.e9e45873.adeason@sinenomine.net> Message-ID: On Mon, Aug 1, 2011 at 1:53 PM, Andrew Deason wrote: > On Mon, 1 Aug 2011 13:32:46 -0400 > Derrick Brashear wrote: > >> On Mon, Aug 1, 2011 at 1:28 PM, Andrew Deason wrote: >> >> >> b) the granularity >> > >> > This one I still have no idea on. I see reasons for both sides. >> >> So is there a reason an extended union with the various stamp >> granularities would be a nonstarter? In particular I'd suggest the >> draft strongly discourage >> sending a larger timestamp than actual information supports (e.g. >> don't use bits to send precision you don't have, rather than >> trailing-zero-padding a >> larger than needed number) > > Well, the objection to just having 64-bit seconds and 32-bit nanoseconds > is "space", and a union tag is an extra 32 bits... If we had a "100 NS > granularity" tag, then we'd have 100-ns granularity in 96 bits, whereas > now we could have 1-ns granularity in 96 bits. Unless there's some other > scheme you're thinking of that somehow makes this more efficient? > This is why in Pittsburgh we proposed that overarching structures (e.g., AFSFetchStatus, and AFSStoreStatus) should be wrapped in ext-union, while proscribing the use of union/ext-union for individual members of those structures. As I suggested last Friday, we could define two different AFSFetchStatus/AFSStoreStatus implied legs for now: one with 64-bit time, and a second with 96-bit time (perhaps, we would also want to define a third leg with 32-bit time--given that we're likely to have implementations of the protocol long before server backing stores can handle the increased resolution)... -Tom From deengert@anl.gov Mon Aug 1 21:47:47 2011 From: deengert@anl.gov (Douglas E. Engert) Date: Mon, 01 Aug 2011 15:47:47 -0500 Subject: [AFS3-std] Election Procedure for AFS-3 Working Group Chairs Message-ID: <4E3710F3.3000603@anl.gov> http://tools.ietf.org/id/draft-wilkinson-afs3-standardisation-00.txt Says its time for an election, typically with nominations starting August 1, for 14 days, voting for 14 days, and 7 days to count with the new chair starting on October 1. It is my position that is up for election, as I have the one year term. Hartmut Reuter is the other co-chair with the 2 year term. Please read section 2.2.2 as to who can be nominated, and who can vote. (We will need a list of eligible voters, from the mailman-owner for our list. Once we get that we can start the nomination process, and keep within the guidelines and have a chair by October 1.) -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From jaltman@secure-endpoints.com Mon Aug 1 22:05:36 2011 From: jaltman@secure-endpoints.com (Jeffrey Altman) Date: Mon, 01 Aug 2011 17:05:36 -0400 Subject: [AFS3-std] Re: A call for consensus on draft-deason-afs3-type-time-02 In-Reply-To: <871ux580f5.fsf@windlord.stanford.edu> References: <20110728135500.76B9ED@grand.central.org> <4E31776B.1040007@odu.edu> <87ei19yma5.fsf@windlord.stanford.edu> <20110729161932.18bc0ced.adeason@sinenomine.net> <87fwlotw4u.fsf@windlord.stanford.edu> <87wrex836y.fsf@windlord.stanford.edu> <4E36E4D7.9010308@secure-endpoints.com> <87fwll81hg.fsf@windlord.stanford.edu> <4E36E9F5.9000502@secure-endpoints.com> <871ux580f5.fsf@windlord.stanford.edu> Message-ID: <4E371520.2050905@secure-endpoints.com> This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF4A4B8C5B5CC41684FB59F42 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 8/1/2011 2:13 PM, Russ Allbery wrote: > Okay, so you *do* care about what epoch is used, unless we use a time > definition that allows for negative offsets from the epoch. I am fine with negative offsets from epoch if that is what people want. > Does Microsoft have documentation for how the Windows epoch deals with > Gregorian calendar conversions and leap seconds? There isn't anything that pops out at me from Google. If you can provide me a list of boundary times to check I can construct a test application that uses SYSTEMTIME to FILETIME conversions to test the results of various time arithmetic operations. typedef struct _SYSTEMTIME { WORD wYear; WORD wMonth; WORD wDayOfWeek; WORD wDay; WORD wHour; WORD wMinute; WORD wSecond; WORD wMilliseconds; } SYSTEMTIME, *PSYSTEMTIME; --------------enigF4A4B8C5B5CC41684FB59F42 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iQEcBAEBAgAGBQJONxUiAAoJENxm1CNJffh4mu4H/A7+rbmqi6FER4MuMi1/q+SY lFwytYN63cqi9l0wcFnOohPlGYHF3NoKG8U71oZiTqLYdjG5mfi/BNQAU4Y+7aQ3 117nRk16TBN3UfdJo8dn/mapBOAlP9Cw9RF0Ac8z9f7416qZ/eHASAsyNiceOvwJ FsiQT9P03z2F+5zEb5/LUn6OGPNVHCB1HVv6TfeUM952Ksd/cmNBgozKlf+rBCDa iiunFEF/2sgHLlaT1iQgZ3TqgfulEJCRwnOSEaD6D+lVTZpCw7AT4UELa/JCNTJj gQ++cQnQ8PFGchd0t0IJhaoqFaAQqT+UZNMNbOvMTo9RkowPHlGqLJy5AbRF91M= =B2Sk -----END PGP SIGNATURE----- --------------enigF4A4B8C5B5CC41684FB59F42-- From shadow@gmail.com Mon Aug 1 22:07:45 2011 From: shadow@gmail.com (Derrick Brashear) Date: Mon, 1 Aug 2011 17:07:45 -0400 Subject: [AFS3-std] Re: A call for consensus on draft-deason-afs3-type-time-02 In-Reply-To: References: <20110728135500.76B9ED@grand.central.org> <4E31776B.1040007@odu.edu> <87ei19yma5.fsf@windlord.stanford.edu> <20110729161932.18bc0ced.adeason@sinenomine.net> <87fwlotw4u.fsf@windlord.stanford.edu> <20110801122810.81b1889c.adeason@sinenomine.net> <20110801125344.e9e45873.adeason@sinenomine.net> Message-ID: On Mon, Aug 1, 2011 at 4:16 PM, Tom Keiser wrote: > On Mon, Aug 1, 2011 at 1:53 PM, Andrew Deason wr= ote: >> On Mon, 1 Aug 2011 13:32:46 -0400 >> Derrick Brashear wrote: >> >>> On Mon, Aug 1, 2011 at 1:28 PM, Andrew Deason = wrote: >>> >>> >> b) the granularity >>> > >>> > This one I still have no idea on. I see reasons for both sides. >>> >>> So is there a reason an extended union with the various stamp >>> granularities would be a nonstarter? In particular I'd suggest the >>> draft strongly discourage >>> sending a larger timestamp than actual information supports (e.g. >>> don't use bits to send precision you don't have, rather than >>> trailing-zero-padding a >>> larger than needed number) >> >> Well, the objection to just having 64-bit seconds and 32-bit nanoseconds >> is "space", and a union tag is an extra 32 bits... If we had a "100 NS >> granularity" tag, then we'd have 100-ns granularity in 96 bits, whereas >> now we could have 1-ns granularity in 96 bits. Unless there's some other >> scheme you're thinking of that somehow makes this more efficient? >> > > This is why in Pittsburgh we proposed that overarching structures > (e.g., AFSFetchStatus, and AFSStoreStatus) should be wrapped in > ext-union, while proscribing the use of union/ext-union for individual > members of those structures. =A0As I suggested last Friday, we could > define two different AFSFetchStatus/AFSStoreStatus implied legs for > now: one with 64-bit time, and a second with 96-bit time (perhaps, we > would also want to define a third leg with 32-bit time--given that > we're likely to have implementations of the protocol long before > server backing stores can handle the increased resolution)... and this approach would be fine for this, at least for a long time in the interim. From rra@stanford.edu Mon Aug 1 22:16:18 2011 From: rra@stanford.edu (Russ Allbery) Date: Mon, 01 Aug 2011 14:16:18 -0700 Subject: [AFS3-std] Re: A call for consensus on draft-deason-afs3-type-time-02 In-Reply-To: <4E371520.2050905@secure-endpoints.com> (Jeffrey Altman's message of "Mon, 01 Aug 2011 17:05:36 -0400") References: <20110728135500.76B9ED@grand.central.org> <4E31776B.1040007@odu.edu> <87ei19yma5.fsf@windlord.stanford.edu> <20110729161932.18bc0ced.adeason@sinenomine.net> <87fwlotw4u.fsf@windlord.stanford.edu> <87wrex836y.fsf@windlord.stanford.edu> <4E36E4D7.9010308@secure-endpoints.com> <87fwll81hg.fsf@windlord.stanford.edu> <4E36E9F5.9000502@secure-endpoints.com> <871ux580f5.fsf@windlord.stanford.edu> <4E371520.2050905@secure-endpoints.com> Message-ID: <87livc6del.fsf@windlord.stanford.edu> Jeffrey Altman writes: > If you can provide me a list of boundary times to check I can construct > a test application that uses SYSTEMTIME to FILETIME conversions to test > the results of various time arithmetic operations. > typedef struct _SYSTEMTIME { > WORD wYear; > WORD wMonth; > WORD wDayOfWeek; > WORD wDay; > WORD wHour; > WORD wMinute; > WORD wSecond; > WORD wMilliseconds; > } SYSTEMTIME, *PSYSTEMTIME; Usually the interesting ones for Gregorian conversion of software written in the US are around the date of UK transition from Julian to Gregorian in September of 1752: September 1752 Su Mo Tu We Th Fr Sa 1 2 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 (gcal is one of the few programs I know that attempts to cope with this.) My guess is that Windows is using a backwards-projection of UTC without leap seconds and not attempting to worry about dates that theoretically should be in Julian, so you'll get an offset of 10 or 11 days relative to the actual historical time when converting from a timestamp to calendar time. -- Russ Allbery (rra@stanford.edu) From jaltman@secure-endpoints.com Mon Aug 1 22:20:06 2011 From: jaltman@secure-endpoints.com (Jeffrey Altman) Date: Mon, 01 Aug 2011 17:20:06 -0400 Subject: [AFS3-std] Re: A call for consensus on draft-deason-afs3-type-time-02 In-Reply-To: <87livc6del.fsf@windlord.stanford.edu> References: <20110728135500.76B9ED@grand.central.org> <4E31776B.1040007@odu.edu> <87ei19yma5.fsf@windlord.stanford.edu> <20110729161932.18bc0ced.adeason@sinenomine.net> <87fwlotw4u.fsf@windlord.stanford.edu> <87wrex836y.fsf@windlord.stanford.edu> <4E36E4D7.9010308@secure-endpoints.com> <87fwll81hg.fsf@windlord.stanford.edu> <4E36E9F5.9000502@secure-endpoints.com> <871ux580f5.fsf@windlord.stanford.edu> <4E371520.2050905@secure-endpoints.com> <87livc6del.fsf@windlord.stanford.edu> Message-ID: <4E371886.8010307@secure-endpoints.com> This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig2647EB98B812449AC7E31696 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 8/1/2011 5:16 PM, Russ Allbery wrote: > Jeffrey Altman writes: >=20 >> If you can provide me a list of boundary times to check I can construc= t >> a test application that uses SYSTEMTIME to FILETIME conversions to tes= t >> the results of various time arithmetic operations. >=20 >> typedef struct _SYSTEMTIME { >> WORD wYear; >> WORD wMonth; >> WORD wDayOfWeek; >> WORD wDay; >> WORD wHour; >> WORD wMinute; >> WORD wSecond; >> WORD wMilliseconds; >> } SYSTEMTIME, *PSYSTEMTIME; >=20 > Usually the interesting ones for Gregorian conversion of software writt= en > in the US are around the date of UK transition from Julian to Gregorian= in > September of 1752: >=20 > September 1752 > Su Mo Tu We Th Fr Sa > 1 2 14 15 16 > 17 18 19 20 21 22 23 > 24 25 26 27 28 29 30 >=20 > (gcal is one of the few programs I know that attempts to cope with this= =2E) >=20 > My guess is that Windows is using a backwards-projection of UTC without= > leap seconds and not attempting to worry about dates that theoretically= > should be in Julian, so you'll get an offset of 10 or 11 days relative = to > the actual historical time when converting from a timestamp to calendar= > time. >=20 Provide times for a few known leap seconds and I can test those as well. --------------enig2647EB98B812449AC7E31696 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iQEcBAEBAgAGBQJONxiIAAoJENxm1CNJffh49/AH/1MZZLyAQ9mIiabhFyZnFHuv FFjEX67+JHztWs7JmIZvz6vEFtrPggpRl2CFXC9kf5dT3eNckXMI3kMEaQRz+YUN cUats8XTrifl8BABP1u9n6xK8DWd3v+YBgrMumCn5ckVUzi+4VaQIrFqBqCfsig2 i2KN9IXVDtyHE5i0pcOxo6lmKYlgN1aMWh8gOSPXep/iQ13YvTWXBqrGxiGjzTLt rfz9AaySkkuVKbVGtRw/WIJn+P1J3MpfPnWWpEVHOfgFJp+1Gv0n5ILUYCpxxlV/ 0AOalh7nl+T/bQDR9oAfDL1kxwRCUCuO1mZbD9XLv+mdcbZ7/muv4PLLkhF85qw= =o4oS -----END PGP SIGNATURE----- --------------enig2647EB98B812449AC7E31696-- From rra@stanford.edu Mon Aug 1 22:30:35 2011 From: rra@stanford.edu (Russ Allbery) Date: Mon, 01 Aug 2011 14:30:35 -0700 Subject: [AFS3-std] Re: A call for consensus on draft-deason-afs3-type-time-02 In-Reply-To: <4E371886.8010307@secure-endpoints.com> (Jeffrey Altman's message of "Mon, 01 Aug 2011 17:20:06 -0400") References: <20110728135500.76B9ED@grand.central.org> <4E31776B.1040007@odu.edu> <87ei19yma5.fsf@windlord.stanford.edu> <20110729161932.18bc0ced.adeason@sinenomine.net> <87fwlotw4u.fsf@windlord.stanford.edu> <87wrex836y.fsf@windlord.stanford.edu> <4E36E4D7.9010308@secure-endpoints.com> <87fwll81hg.fsf@windlord.stanford.edu> <4E36E9F5.9000502@secure-endpoints.com> <871ux580f5.fsf@windlord.stanford.edu> <4E371520.2050905@secure-endpoints.com> <87livc6del.fsf@windlord.stanford.edu> <4E371886.8010307@secure-endpoints.com> Message-ID: <87bow86cqs.fsf@windlord.stanford.edu> Jeffrey Altman writes: > Provide times for a few known leap seconds and I can test those as well. Leap seconds are always added as 23:60 on June 30th or December 31st. There's a table at: http://en.wikipedia.org/wiki/Leap_second of all the leap seconds that have been added historically. So: 1972-06-30 23:59:59 1972-06-30 23:59:60 1972-07-01 00:00:00 for example. One of the interesting questions is whether conversion of the first and last calendar times above are, when represented as timestamps, one second apart or two seconds apart. Note that, in POSIX, they're one second apart, because POSIX time contains no leap seconds by definition (which means that it's not really possible to accurately represent those dates). On UNIX systems, using mktime on those dates will generally convert as follows: 1972-06-30 23:59:59 78821999 1972-06-30 23:59:60 78822000 1972-07-01 00:00:00 78822000 There's not really a "right" answer here; we just need to say what the answer is. -- Russ Allbery (rra@stanford.edu) From jhutz@cmu.edu Tue Aug 2 00:17:16 2011 From: jhutz@cmu.edu (Jeffrey Hutzelman) Date: Mon, 01 Aug 2011 19:17:16 -0400 Subject: [AFS3-std] Re: Election Procedure for AFS-3 Working Group Chairs In-Reply-To: <4E3710F3.3000603@anl.gov> References: <4E3710F3.3000603@anl.gov> Message-ID: <1312240636.3168.25.camel@destiny.pc.cs.cmu.edu> On Mon, 2011-08-01 at 15:47 -0500, Douglas E. Engert wrote: > http://tools.ietf.org/id/draft-wilkinson-afs3-standardisation-00.txt > > Says its time for an election, typically with nominations starting > August 1, for 14 days, voting for 14 days, and 7 days to count with > the new chair starting on October 1. > > It is my position that is up for election, as I have the one year > term. Hartmut Reuter is the other co-chair with the 2 year term. > > Please read section 2.2.2 as to who can be nominated, and who can vote. > > (We will need a list of eligible voters, from the mailman-owner > for our list. Once we get that we can start the nomination process, > and keep within the guidelines and have a chair by October 1.) According to section 2.2.2, the list of eligible voters consists of anyone who has posted or was subscribed during the period from June 1 to July 1. It's fairly easy to construct a list of who has posted by consulting the list archives, which are publicly available at https://lists.openafs.org/pipermail/afs3-standardization/ The subscriber list is not public; however, any subscriber can obtain a copy by filling in his username and password near the bottom of the page at https://lists.openafs.org/mailman/listinfo/afs3-standardization and selecting "Visit Subscriber List". Of course, that's as of today. To build a voter list, you also need to know that there have been no new subscribers and no one has unsubscribed since April 25, before the start of the eligibility period. -- Jeff From deengert@anl.gov Tue Aug 2 17:26:34 2011 From: deengert@anl.gov (Douglas E. Engert) Date: Tue, 02 Aug 2011 11:26:34 -0500 Subject: [AFS3-std] Call for nomination for the position of AFS3-standardization co-chair Message-ID: <4E38253A.6000001@anl.gov> http://tools.ietf.org/id/draft-wilkinson-afs3-standardisation-00.txt defines our election procedures to elect a co-chair. It is my position that is up for election, as I have the one year term. Hartmut Reuter is the other co-chair with the 2 year term, due to expire next year. Schedule: Nominations open 8/2 - 8/16 Announcement of nominations 8/17 Voting 8-17 - 8/31 Election results 9/7 Please read section 2.2.2 as to who can be nominated, and who can vote. Send nominations to Hartmut and myself as the vote takers, and we can contact the potential nominees to make sure they are willing to serve. As Jeff points out: > The subscriber list is not public; however, any subscriber can obtain a > copy by filling in his username and password near the bottom of the page > at https://lists.openafs.org/mailman/listinfo/afs3-standardization and > selecting "Visit Subscriber List". Of course, that's as of today. To > build a voter list, you also need to know that there have been no new > subscribers and no one has unsubscribed since April 25, before the start > of the eligibility period. (You can also get your password sent to you with the "Edit Options") -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From deengert@anl.gov Fri Aug 5 20:32:15 2011 From: deengert@anl.gov (Douglas E. Engert) Date: Fri, 05 Aug 2011 14:32:15 -0500 Subject: [AFS3-std] Call for nomination for the position of AFS3-standardization co-chair In-Reply-To: <4E38253A.6000001@anl.gov> References: <4E38253A.6000001@anl.gov> Message-ID: <4E3C453F.5060805@anl.gov> I am not running for re-election and so far we have receive only one other nomination. See the schedule below. On 8/2/2011 11:26 AM, Douglas E. Engert wrote: > http://tools.ietf.org/id/draft-wilkinson-afs3-standardisation-00.txt > > defines our election procedures to elect a co-chair. It is my position > that is up for election, as I have the one year term. Hartmut Reuter > is the other co-chair with the 2 year term, due to expire next year. > > Schedule: > Nominations open 8/2 - 8/16 > Announcement of nominations 8/17 > Voting 8-17 - 8/31 > Election results 9/7 > > Please read section 2.2.2 as to who can be nominated, and who can vote. > > Send nominations to Hartmut and myself as the vote takers, and we can > contact the potential nominees to make sure they are willing to serve. > > As Jeff points out: > > The subscriber list is not public; however, any subscriber can obtain a > > copy by filling in his username and password near the bottom of the page > > at https://lists.openafs.org/mailman/listinfo/afs3-standardization and > > selecting "Visit Subscriber List". Of course, that's as of today. To > > build a voter list, you also need to know that there have been no new > > subscribers and no one has unsubscribed since April 25, before the start > > of the eligibility period. > > (You can also get your password sent to you with the "Edit Options") > -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From adeason@sinenomine.net Mon Aug 8 18:32:58 2011 From: adeason@sinenomine.net (Andrew Deason) Date: Mon, 8 Aug 2011 12:32:58 -0500 Subject: [AFS3-std] Re: A call for consensus on draft-deason-afs3-type-time-02 References: <20110728135500.76B9ED@grand.central.org> <4E31776B.1040007@odu.edu> <87ei19yma5.fsf@windlord.stanford.edu> <20110729161932.18bc0ced.adeason@sinenomine.net> <87fwlotw4u.fsf@windlord.stanford.edu> Message-ID: <20110808123258.59cc0539.adeason@sinenomine.net> On Fri, 29 Jul 2011 18:06:25 -0700 Russ Allbery wrote: > Or, hm, I suppose if you squint at it right, you can decide that > "number of seconds" isn't just elapsed actual time, but includes the > leap seconds that were inserted. Which would also work for our > phrasing. Maybe we could just say that explicitly. Something like: > > the number of seconds and nanoseconds since midnight or 0 hour > January 1, 1970 Coordinated Universal Time (UTC), including any > leap seconds inserted into UTC. It's very possible I am backwards on this, but shouldn't this be "excluding any leap seconds"? That is, in our time representation, there is a difference of 1 "second" (however we define "second") between the times 31 Dec 2005 23:59:59 and 01 Jan 2006 00:00:00, even though there was a leap second at 31 Dec 2005 23:59:60. That is, I thought we'd be following UTC more than TAI. And also, I did find another instance of this being mentioned in IETF RFCs. RFC 4049 states in Section 2 (at the top of the second page): The integer value is the number of seconds, excluding leap seconds, after midnight UTC, January 1, 1970. Would that work for us? -- Andrew Deason adeason@sinenomine.net From rra@stanford.edu Mon Aug 8 18:50:11 2011 From: rra@stanford.edu (Russ Allbery) Date: Mon, 08 Aug 2011 10:50:11 -0700 Subject: [AFS3-std] Re: A call for consensus on draft-deason-afs3-type-time-02 In-Reply-To: <20110808123258.59cc0539.adeason@sinenomine.net> (Andrew Deason's message of "Mon, 8 Aug 2011 12:32:58 -0500") References: <20110728135500.76B9ED@grand.central.org> <4E31776B.1040007@odu.edu> <87ei19yma5.fsf@windlord.stanford.edu> <20110729161932.18bc0ced.adeason@sinenomine.net> <87fwlotw4u.fsf@windlord.stanford.edu> <20110808123258.59cc0539.adeason@sinenomine.net> Message-ID: <8762m7ztbg.fsf@windlord.stanford.edu> Andrew Deason writes: > Russ Allbery wrote: >> Or, hm, I suppose if you squint at it right, you can decide that >> "number of seconds" isn't just elapsed actual time, but includes the >> leap seconds that were inserted. Which would also work for our >> phrasing. Maybe we could just say that explicitly. Something like: >> >> the number of seconds and nanoseconds since midnight or 0 hour >> January 1, 1970 Coordinated Universal Time (UTC), including any >> leap seconds inserted into UTC. > It's very possible I am backwards on this, but shouldn't this be > "excluding any leap seconds"? Oh, yes, you're exactly right. Thank you. > That is, in our time representation, there is a difference of 1 "second" > (however we define "second") between the times 31 Dec 2005 23:59:59 and > 01 Jan 2006 00:00:00, even though there was a leap second at 31 Dec 2005 > 23:59:60. That is, I thought we'd be following UTC more than TAI. Yes, correct. > And also, I did find another instance of this being mentioned in IETF > RFCs. RFC 4049 states in Section 2 (at the top of the second page): > The integer value is the number of seconds, excluding leap seconds, > after midnight UTC, January 1, 1970. > Would that work for us? That sounds great to me. We could take the same approach if we use the other epoch, although I think we should be more wordy about it: The integer value is the number of seconds, excluding leap seconds, after midnight, January 1, 1601 Coordinated Universal Time (UTC), in the Gregorian calendar. NOTE: Neither the Gregorian calendar or the modern UTC time zone were in use in most of the world at that date, but times are represented as if they were, using the obvious backwards projection of the current UTC time zone and Gregorian calendar rules to January 1, 1601. Be aware that any real-world times from that era will likely require Julian to Gregorian calendar conversions to be represented in this format and probably cannot be simply converted using normal time conversions from the modern era. I think that phrasing would resolve my objections to the epoch, along with the additional bits that are in the current draft about how to convert. -- Russ Allbery (rra@stanford.edu) From adeason@sinenomine.net Mon Aug 8 18:54:03 2011 From: adeason@sinenomine.net (Andrew Deason) Date: Mon, 8 Aug 2011 12:54:03 -0500 Subject: [AFS3-std] Re: A call for consensus on draft-deason-afs3-type-time-02 References: <4E2082C6.80609@anl.gov> Message-ID: <20110808125403.f9b913b3.adeason@sinenomine.net> On Fri, 15 Jul 2011 13:11:18 -0500 "Douglas E. Engert" wrote: > http://datatracker.ietf.org/doc/draft-deason-afs3-type-time/ Based on the threads in afs3-stds, and on discussions I've had with others, I propose the following going forward. This is what I'm working on for an -03 draft, and it's what will appear unless I hear objections. The epoch will be changed to the Unix epoch. Absolute time will be signed so we can still represent the windows stuff. The language will also be changed a bit according to Russ's suggestions ("number of seconds since 1970 excluding leap seconds" or whatever it turns out to be, see this sub-thread: ). The granularity in this draft will not be changed. However, additional types will be proposed to be used for higher efficiency and higher granularity. That is, the current types will be AFSAbsTime64 which corresponds to 64-bit 100-ns time, but we will also have types such as AFSAbsTime32 (32-bit 1-s time) and AFSAbsTime96 (64-bit 1-s time plus 32-bit 1-ns). RPCs for which this matters will use some way of accomodating and specifying these other types, but how they do so is outside the scope of this draft (in theory this could be unions, extended unions, separate RPCs etc; in practice right now we expect extended unions). In the interest of getting this i-d done as quickly as we can, the other time types will not be added to this draft, but will be proposed in separate i-ds and if we need to we can argue about them then. So, the only change for draft-deason-afs3-type-time is that the type names will be changed to AFSAbsTime64 etc, and I will include a paragraph discussing the rationale and the future use of other time types for interoperability and efficiency. I feel this will satisfy everyone's concerns, as this approach should allow us to interoperate well with other systems, but the common case should be kept nearly as efficient as the current draft. -- Andrew Deason adeason@sinenomine.net From adeason@sinenomine.net Mon Aug 8 18:58:57 2011 From: adeason@sinenomine.net (Andrew Deason) Date: Mon, 8 Aug 2011 12:58:57 -0500 Subject: [AFS3-std] Re: A call for consensus on draft-deason-afs3-type-time-02 References: <20110728135500.76B9ED@grand.central.org> <4E31776B.1040007@odu.edu> <87ei19yma5.fsf@windlord.stanford.edu> <20110729161932.18bc0ced.adeason@sinenomine.net> <87fwlotw4u.fsf@windlord.stanford.edu> <20110808123258.59cc0539.adeason@sinenomine.net> <8762m7ztbg.fsf@windlord.stanford.edu> Message-ID: <20110808125857.a055922a.adeason@sinenomine.net> On Mon, 08 Aug 2011 10:50:11 -0700 Russ Allbery wrote: > We could take the same approach if we use the other epoch, although I > think we should be more wordy about it: Oh, I thought we'd just use the Unix epoch since it just makes some of this easier. A note on converting to pre-UTC dates seems good, though. Also just by the way, NTPv4 apparently uses an epoch in 1900. They have this to say about it in RFC 5905: In the date and timestamp formats, the prime epoch, or base date of era 0, is 0 h 1 January 1900 UTC, when all bits are zero. It should be noted that strictly speaking, UTC did not exist prior to 1 January 1972, but it is convenient to assume it has existed for all eternity, even if all knowledge of historic leap seconds has been lost. -- Andrew Deason adeason@sinenomine.net From rra@stanford.edu Mon Aug 8 20:50:40 2011 From: rra@stanford.edu (Russ Allbery) Date: Mon, 08 Aug 2011 12:50:40 -0700 Subject: [AFS3-std] Re: A call for consensus on draft-deason-afs3-type-time-02 In-Reply-To: <20110808125857.a055922a.adeason@sinenomine.net> (Andrew Deason's message of "Mon, 8 Aug 2011 12:58:57 -0500") References: <20110728135500.76B9ED@grand.central.org> <4E31776B.1040007@odu.edu> <87ei19yma5.fsf@windlord.stanford.edu> <20110729161932.18bc0ced.adeason@sinenomine.net> <87fwlotw4u.fsf@windlord.stanford.edu> <20110808123258.59cc0539.adeason@sinenomine.net> <8762m7ztbg.fsf@windlord.stanford.edu> <20110808125857.a055922a.adeason@sinenomine.net> Message-ID: <87k4any967.fsf@windlord.stanford.edu> Andrew Deason writes: > Russ Allbery wrote: >> We could take the same approach if we use the other epoch, although I >> think we should be more wordy about it: > Oh, I thought we'd just use the Unix epoch since it just makes some of > this easier. A note on converting to pre-UTC dates seems good, though. Jeffrey has a good point, though: we lose representability of dates that can currently be handled with CIFS. > Also just by the way, NTPv4 apparently uses an epoch in 1900. They have > this to say about it in RFC 5905: > In the date and timestamp formats, the prime epoch, or base date of > era 0, is 0 h 1 January 1900 UTC, when all bits are zero. It should > be noted that strictly speaking, UTC did not exist prior to 1 > January 1972, but it is convenient to assume it has existed for all > eternity, even if all knowledge of historic leap seconds has been > lost. Yeah, that's similar in intention to my note. -- Russ Allbery (rra@stanford.edu) From adeason@sinenomine.net Mon Aug 8 21:42:13 2011 From: adeason@sinenomine.net (Andrew Deason) Date: Mon, 8 Aug 2011 15:42:13 -0500 Subject: [AFS3-std] Re: A call for consensus on draft-deason-afs3-type-time-02 References: <20110728135500.76B9ED@grand.central.org> <4E31776B.1040007@odu.edu> <87ei19yma5.fsf@windlord.stanford.edu> <20110729161932.18bc0ced.adeason@sinenomine.net> <87fwlotw4u.fsf@windlord.stanford.edu> <20110808123258.59cc0539.adeason@sinenomine.net> <8762m7ztbg.fsf@windlord.stanford.edu> <20110808125857.a055922a.adeason@sinenomine.net> <87k4any967.fsf@windlord.stanford.edu> Message-ID: <20110808154213.4ce21908.adeason@sinenomine.net> On Mon, 08 Aug 2011 12:50:40 -0700 Russ Allbery wrote: > Andrew Deason writes: > > Oh, I thought we'd just use the Unix epoch since it just makes some > > of this easier. A note on converting to pre-UTC dates seems good, > > though. > > Jeffrey has a good point, though: we lose representability of dates > that can currently be handled with CIFS. Then we just make the absolute timestamps signed. It just seems better to me to start from an epoch that's a bit more well-defined (or at least, more easily well-defined; we can always define 1 Jan 1600 as X seconds before 1 Jan 1970, but that seems strangely indirect). -- Andrew Deason adeason@sinenomine.net From rra@stanford.edu Mon Aug 8 21:49:42 2011 From: rra@stanford.edu (Russ Allbery) Date: Mon, 08 Aug 2011 13:49:42 -0700 Subject: [AFS3-std] Re: A call for consensus on draft-deason-afs3-type-time-02 In-Reply-To: <20110808154213.4ce21908.adeason@sinenomine.net> (Andrew Deason's message of "Mon, 8 Aug 2011 15:42:13 -0500") References: <20110728135500.76B9ED@grand.central.org> <4E31776B.1040007@odu.edu> <87ei19yma5.fsf@windlord.stanford.edu> <20110729161932.18bc0ced.adeason@sinenomine.net> <87fwlotw4u.fsf@windlord.stanford.edu> <20110808123258.59cc0539.adeason@sinenomine.net> <8762m7ztbg.fsf@windlord.stanford.edu> <20110808125857.a055922a.adeason@sinenomine.net> <87k4any967.fsf@windlord.stanford.edu> <20110808154213.4ce21908.adeason@sinenomine.net> Message-ID: <87sjpbwrvd.fsf@windlord.stanford.edu> Andrew Deason writes: > Russ Allbery wrote: >> Jeffrey has a good point, though: we lose representability of dates >> that can currently be handled with CIFS. > Then we just make the absolute timestamps signed. It just seems better > to me to start from an epoch that's a bit more well-defined (or at > least, more easily well-defined; we can always define 1 Jan 1600 as X > seconds before 1 Jan 1970, but that seems strangely indirect). I guess I'm ambivalent between signed timestamps and the Windows epoch. Both of them are going to be at least somewhat unusual for typical UNIX code. My guess is that it will be easier to explain the Windows epoch than it will be to explain signed arithmetic on times, but I could be wrong. -- Russ Allbery (rra@stanford.edu) From jaltman@secure-endpoints.com Mon Aug 8 22:25:48 2011 From: jaltman@secure-endpoints.com (Jeffrey Altman) Date: Mon, 08 Aug 2011 17:25:48 -0400 Subject: [AFS3-std] Re: A call for consensus on draft-deason-afs3-type-time-02 In-Reply-To: <20110808154213.4ce21908.adeason@sinenomine.net> References: <20110728135500.76B9ED@grand.central.org> <4E31776B.1040007@odu.edu> <87ei19yma5.fsf@windlord.stanford.edu> <20110729161932.18bc0ced.adeason@sinenomine.net> <87fwlotw4u.fsf@windlord.stanford.edu> <20110808123258.59cc0539.adeason@sinenomine.net> <8762m7ztbg.fsf@windlord.stanford.edu> <20110808125857.a055922a.adeason@sinenomine.net> <87k4any967.fsf@windlord.stanford.edu> <20110808154213.4ce21908.adeason@sinenomine.net> Message-ID: <4E40545C.6080600@secure-endpoints.com> This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig4AFFD422C27516B82CF3A430 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 8/8/2011 4:42 PM, Andrew Deason wrote: > On Mon, 08 Aug 2011 12:50:40 -0700 > Russ Allbery wrote: >=20 >> Andrew Deason writes: >>> Oh, I thought we'd just use the Unix epoch since it just makes some >>> of this easier. A note on converting to pre-UTC dates seems good, >>> though. >> >> Jeffrey has a good point, though: we lose representability of dates >> that can currently be handled with CIFS. >=20 > Then we just make the absolute timestamps signed. It just seems better > to me to start from an epoch that's a bit more well-defined (or at > least, more easily well-defined; we can always define 1 Jan 1600 as X > seconds before 1 Jan 1970, but that seems strangely indirect). I don't have a strong feeling about the epoch. I am fine with negative timestamp values. --------------enig4AFFD422C27516B82CF3A430 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iQEcBAEBAgAGBQJOQFRfAAoJENxm1CNJffh41zQH/1a3yikgeEdDGPesg+i901Bu vj/9ivedJ558iUUp4IuR4lC+JB236gh9AH0Mb5lt3FTPkfkX7nM+K9ZH5zDHFhSO O+6TPvMtogJZi94yB7O/1M0cWy+D2NbY+glWBtZCzzOYf1xOyrgSozr+D6xwykS/ pVE8NpJ4zApX/94d1pNWXa+wIRSQO1RTJ2nQR8hLCMGUFaQapwKmpAPKhglKJFFH Jl9gvt9Pb5eCFiqq5VO+ps49Ny8lCYL/49HMeF1jGSJyWs8cDJklKq3BFCn5ansd HzN0ksSlJC6YRlj12EtacdoG0hrym2+BNCMNh2MdPduR24av5D7Aiur0b2rrWb4= =47yu -----END PGP SIGNATURE----- --------------enig4AFFD422C27516B82CF3A430-- From deengert@anl.gov Wed Aug 10 13:48:38 2011 From: deengert@anl.gov (Douglas E. Engert) Date: Wed, 10 Aug 2011 07:48:38 -0500 Subject: [AFS3-std] Call for nomination for the position of AFS3-standardization co-chair In-Reply-To: <4E38253A.6000001@anl.gov> References: <4E38253A.6000001@anl.gov> Message-ID: <4E427E26.9040009@anl.gov> Let me restate this again, we have received only one nomination, so I have also nominated 2 people. We are waiting for these 3 people to respond that they would be willing to run. So please send in nominations to Hartmut and myself. On 8/2/2011 11:26 AM, Douglas E. Engert wrote: > http://tools.ietf.org/id/draft-wilkinson-afs3-standardisation-00.txt > > defines our election procedures to elect a co-chair. It is my position > that is up for election, as I have the one year term. Hartmut Reuter > is the other co-chair with the 2 year term, due to expire next year. > > Schedule: > Nominations open 8/2 - 8/16 > Announcement of nominations 8/17 > Voting 8-17 - 8/31 > Election results 9/7 > > Please read section 2.2.2 as to who can be nominated, and who can vote. > > Send nominations to Hartmut and myself as the vote takers, and we can > contact the potential nominees to make sure they are willing to serve. > > As Jeff points out: > > The subscriber list is not public; however, any subscriber can obtain a > > copy by filling in his username and password near the bottom of the page > > at https://lists.openafs.org/mailman/listinfo/afs3-standardization and > > selecting "Visit Subscriber List". Of course, that's as of today. To > > build a voter list, you also need to know that there have been no new > > subscribers and no one has unsubscribed since April 25, before the start > > of the eligibility period. > > (You can also get your password sent to you with the "Edit Options") > -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 _______________________________________________ AFS3-standardization mailing list AFS3-standardization@openafs.org http://lists.openafs.org/mailman/listinfo/afs3-standardization From jhutz@cmu.edu Wed Aug 10 13:58:17 2011 From: jhutz@cmu.edu (Jeffrey Hutzelman) Date: Wed, 10 Aug 2011 08:58:17 -0400 Subject: [AFS3-std] Call for nomination for the position of AFS3-standardization co-chair In-Reply-To: <4E427E26.9040009@anl.gov> References: <4E38253A.6000001@anl.gov> <4E427E26.9040009@anl.gov> Message-ID: <1312981097.3168.159.camel@destiny.pc.cs.cmu.edu> On Wed, 2011-08-10 at 07:48 -0500, Douglas E. Engert wrote: > Let me restate this again, we have received only one nomination, > so I have also nominated 2 people. We are waiting for these 3 > people to respond that they would be willing to run. Per 2.2.2, nominations are supposed to be sent to this mailing list, and each nomination should be made and seconded by eligible voters. I don't see that any nominations have gone to the list so far. It would be good if those who have already made nominations would copy them to the list; otherwise it will be hard to get a second. :-) -- Jeff From deengert@anl.gov Wed Aug 10 14:08:24 2011 From: deengert@anl.gov (Douglas E. Engert) Date: Wed, 10 Aug 2011 08:08:24 -0500 Subject: [AFS3-std] Call for nomination for the position of AFS3-standardization co-chair In-Reply-To: <1312981097.3168.159.camel@destiny.pc.cs.cmu.edu> References: <4E38253A.6000001@anl.gov> <4E427E26.9040009@anl.gov> <1312981097.3168.159.camel@destiny.pc.cs.cmu.edu> Message-ID: <4E4282C8.8030702@anl.gov> On 8/10/2011 7:58 AM, Jeffrey Hutzelman wrote: > On Wed, 2011-08-10 at 07:48 -0500, Douglas E. Engert wrote: >> Let me restate this again, we have received only one nomination, >> so I have also nominated 2 people. We are waiting for these 3 >> people to respond that they would be willing to run. > > Per 2.2.2, nominations are supposed to be sent to this mailing list, and > each nomination should be made and seconded by eligible voters. I don't > see that any nominations have gone to the list so far. It would be good > if those who have already made nominations would copy them to the list; > otherwise it will be hard to get a second. :-) Good point. So far no one has indicated that they are "Any consenting individual" so I have not put their name out. The other note sent to the vote takers, gave a name, and I am waiting for a reply as to weither that individual is willing. > > -- Jeff > > -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From deengert@anl.gov Wed Aug 10 14:45:50 2011 From: deengert@anl.gov (Douglas E. Engert) Date: Wed, 10 Aug 2011 08:45:50 -0500 Subject: [AFS3-std] Call for nomination for the position of AFS3-standardization co-chair In-Reply-To: <4E38253A.6000001@anl.gov> References: <4E38253A.6000001@anl.gov> Message-ID: <4E428B8E.9040602@anl.gov> I (as a group member, not as co-chair) would like to place in nomination for the co-chair of the AFS3-standardization group, Jeffrey Hutzelman. Jeff's IETF experiences, knowledge of AFS, and organizations skills make him an ideal candidate for the position. On 8/2/2011 11:26 AM, Douglas E. Engert wrote: > http://tools.ietf.org/id/draft-wilkinson-afs3-standardisation-00.txt > > defines our election procedures to elect a co-chair. It is my position > that is up for election, as I have the one year term. Hartmut Reuter > is the other co-chair with the 2 year term, due to expire next year. > > Schedule: > Nominations open 8/2 - 8/16 > Announcement of nominations 8/17 > Voting 8-17 - 8/31 > Election results 9/7 > > Please read section 2.2.2 as to who can be nominated, and who can vote. > > Send nominations to Hartmut and myself as the vote takers, and we can > contact the potential nominees to make sure they are willing to serve. > > As Jeff points out: > > The subscriber list is not public; however, any subscriber can obtain a > > copy by filling in his username and password near the bottom of the page > > at https://lists.openafs.org/mailman/listinfo/afs3-standardization and > > selecting "Visit Subscriber List". Of course, that's as of today. To > > build a voter list, you also need to know that there have been no new > > subscribers and no one has unsubscribed since April 25, before the start > > of the eligibility period. > > (You can also get your password sent to you with the "Edit Options") > -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From matt@linuxbox.com Wed Aug 10 15:10:02 2011 From: matt@linuxbox.com (Matt W. Benjamin) Date: Wed, 10 Aug 2011 10:10:02 -0400 (EDT) Subject: [AFS3-std] Call for nomination for the position of AFS3-standardization co-chair In-Reply-To: <4E428B8E.9040602@anl.gov> Message-ID: <562730635.18.1312985402484.JavaMail.root@thunderbeast.private.linuxbox.com> Second. ----- "Douglas E. Engert" wrote: > I (as a group member, not as co-chair) would like to place in > nomination > for the co-chair of the AFS3-standardization group, Jeffrey > Hutzelman. > > Jeff's IETF experiences, knowledge of AFS, and > organizations skills make him an ideal candidate for the position. > > -- Matt Benjamin The Linux Box 206 South Fifth Ave. Suite 150 Ann Arbor, MI 48104 http://linuxbox.com tel. 734-761-4689 fax. 734-769-8938 cel. 734-216-5309 From jaltman@secure-endpoints.com Wed Aug 10 16:00:04 2011 From: jaltman@secure-endpoints.com (Jeffrey Altman) Date: Wed, 10 Aug 2011 11:00:04 -0400 Subject: [AFS3-std] Call for nomination for the position of AFS3-standardization co-chair In-Reply-To: <562730635.18.1312985402484.JavaMail.root@thunderbeast.private.linuxbox.com> References: <562730635.18.1312985402484.JavaMail.root@thunderbeast.private.linuxbox.com> Message-ID: <4E429CF4.5060705@secure-endpoints.com> This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig4E96346D395F7DE12DCC99A3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 8/10/2011 10:10 AM, Matt W. Benjamin wrote: > Second. >=20 > ----- "Douglas E. Engert" wrote: >=20 >> I (as a group member, not as co-chair) would like to place in >> nomination >> for the co-chair of the AFS3-standardization group, Jeffrey >> Hutzelman. >> >> Jeff's IETF experiences, knowledge of AFS, and >> organizations skills make him an ideal candidate for the position. >> >> I believe that Jeff would make an excellent chair (if he has time) but would prefer that the Chair not also be a registrar. --------------enig4E96346D395F7DE12DCC99A3 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iQEcBAEBAgAGBQJOQpz3AAoJENxm1CNJffh4YcYH/2UAYaa+ASU7rCdoqMODFk1D efEUmqC1fwllQ+RCfTLzBJdLUM/9a0tT4/EPmKtfQ+TqGAAfe56ncmykpwDsSM+w qsNOPxC+5J9YpAi9CCsNx0i6ynuTAd7i/pLrxl2ZbBGIgHXcTx+GqVLneummsdvb I4KLDxYYIZOhz6LTywKZBIfrm5JuO3SUI1W8JQ+1BbTXjyRl6u+N5qW+8p4JGy0q G7ZXnLMmJwYuW8XqaJqG+q0LOuGiKcggYX9Gzs9o4lGp0B+l0Jf2LftM1Vp8epUO aBAVyhW7MF3tZQEys3K0/r6GVnSiQqJuAB01FTzD5M86wdsnuLp7XW/njYcuy+Y= =EpGd -----END PGP SIGNATURE----- --------------enig4E96346D395F7DE12DCC99A3-- From deengert@anl.gov Wed Aug 10 16:22:50 2011 From: deengert@anl.gov (Douglas E. Engert) Date: Wed, 10 Aug 2011 10:22:50 -0500 Subject: [AFS3-std] Call for nomination for the position of AFS3-standardization co-chair In-Reply-To: <4E429CF4.5060705@secure-endpoints.com> References: <562730635.18.1312985402484.JavaMail.root@thunderbeast.private.linuxbox.com> <4E429CF4.5060705@secure-endpoints.com> Message-ID: <4E42A24A.6090206@anl.gov> On 8/10/2011 10:00 AM, Jeffrey Altman wrote: > On 8/10/2011 10:10 AM, Matt W. Benjamin wrote: >> Second. >> >> ----- "Douglas E. Engert" wrote: >> >>> I (as a group member, not as co-chair) would like to place in >>> nomination >>> for the co-chair of the AFS3-standardization group, Jeffrey >>> Hutzelman. >>> >>> Jeff's IETF experiences, knowledge of AFS, and >>> organizations skills make him an ideal candidate for the position. >>> >>> > > I believe that Jeff would make an excellent chair (if he has time) but > would prefer that the Chair not also be a registrar. I understand. Section 2.3.2 says: "it is proposed to extend the role of registrar to include a number of individuals from the community." So the work could be spread around if that is the issue. > > -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From scs@umich.edu Wed Aug 10 16:53:37 2011 From: scs@umich.edu (Steve Simmons) Date: Wed, 10 Aug 2011 11:53:37 -0400 Subject: [AFS3-std] Re: A call for consensus on draft-deason-afs3-type-time-02 In-Reply-To: <87bow86cqs.fsf@windlord.stanford.edu> References: <20110728135500.76B9ED@grand.central.org> <4E31776B.1040007@odu.edu> <87ei19yma5.fsf@windlord.stanford.edu> <20110729161932.18bc0ced.adeason@sinenomine.net> <87fwlotw4u.fsf@windlord.stanford.edu> <87wrex836y.fsf@windlord.stanford.edu> <4E36E4D7.9010308@secure-endpoints.com> <87fwll81hg.fsf@windlord.stanford.edu> <4E36E9F5.9000502@secure-endpoints.com> <871ux580f5.fsf@windlord.stanford.edu> <4E371520.2050905@secure-endpoints.com> <87livc6del.fsf@windlord.stanford.edu> <4E371886.8010307@secure-endpoints.com> <87bow86cqs.fsf@windlord.stanford.edu> Message-ID: <11B3F212-2286-4452-9917-88D390C380BD@umich.edu> On Aug 1, 2011, at 5:30 PM, Russ Allbery wrote: > . . . One of the interesting questions is whether conversion of > the first and last calendar times above are, when represented as > timestamps, one second apart or two seconds apart. >=20 > Note that, in POSIX, they're one second apart, because POSIX time = contains > no leap seconds by definition (which means that it's not really = possible > to accurately represent those dates). >=20 > On UNIX systems, using mktime on those dates will generally convert as > follows: >=20 > 1972-06-30 23:59:59 78821999 > 1972-06-30 23:59:60 78822000 > 1972-07-01 00:00:00 78822000 >=20 > There's not really a "right" answer here; we just need to say what the > answer is. The last paragraph says it, both w/r/t the POSIX issues above and the = various other time issues discussed in this thread. We don't need to be = absolutely right*, nor do we necessarily need to be fully in agreement = with any other vendor or standards system. We just need to say what we = are doing. I proposed we be broken in the same way POSIX is broken, rather than = being any other brand of broken or inventing our own. :-) Steve * IMHO 'absolutely right' would involved knowing what is right, and = presenting to all the other broken implementations their expected broken = data. The former is beyond our scope and abilities, the latter . . . = well, that way lies madness. Let's face it, 99.99% of the time all we're = talking about are filesystem timestamps. If someone wants to touch a = file with the date Sept 10 1752 and not specify anything else about how = to interpret that date, they deserve the wrongness they get. And anybody = who's doing work where leap seconds and calendar type transitions matter = is not doing it using POSIX, Windows, or any other OS-time = representation.** ** No, I have no freaking idea what they're using.= From deengert@anl.gov Wed Aug 10 22:15:26 2011 From: deengert@anl.gov (Douglas E. Engert) Date: Wed, 10 Aug 2011 16:15:26 -0500 Subject: [AFS3-std] AFS3-standardization Co-Chair Nominations time commitments Message-ID: <4E42F4EE.7020807@anl.gov> One of the potential nominees asked: > Can you give me some idea of what time commitment is required? So far it has been only a few hours a week, but depending on how much you want to get involved, and how many drafts are active, it could be more. There are no meeting you have to attend, and the duties of a co-chair are to keep the group inline, and moving. A co-chair could then leave it up to the author of a draft to handle all the issues for a draft or get more involved if this is not happening. (So far that has not been a problem.) The chair does not have to be an expert in the details of a draft, but needs to recognize that others in the group have issues and if there is general consensuses for a draft. After consensuses, we are submitting our drafts as IETF Independent Submissions to the RFC editor. As this process is designed for individuals, not groups, I have left the submission up to the authors. We are breaking ground as a group in submitting a group approved draft in this way. We have our first draft in that state waiting for the three reviewers (they know who they are) to get their reviews in to the RFC Editor. I have had some e-mail discussions with the IETF RFC Editor on this process. on behalf of the group. When the first draft is reviewed, I expect that there will be some additional text that needs to be added to the draft, and to all our drafts. The individual authors of the drafts will have to do this. It is up to the Chair to keep after them. There are two chairs, Hartmut is the co-chair, for one more year, and the new co-chair will have a 2 year term. So it is up to the chairs how the work is split, and how much time you want to put into it. -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From adeason@sinenomine.net Fri Aug 12 17:31:02 2011 From: adeason@sinenomine.net (Andrew Deason) Date: Fri, 12 Aug 2011 11:31:02 -0500 Subject: [AFS3-std] Re: Call for nomination for the position of AFS3-standardization co-chair In-Reply-To: <4E38253A.6000001@anl.gov> References: <4E38253A.6000001@anl.gov> Message-ID: <20110812113102.6efde0c0.adeason@sinenomine.net> I nominate Mike Meffie for co-chair of the AFS3 standardization group. -- Andrew Deason adeason@sinenomine.net From jhutz@cmu.edu Fri Aug 12 22:08:57 2011 From: jhutz@cmu.edu (Jeffrey Hutzelman) Date: Fri, 12 Aug 2011 17:08:57 -0400 Subject: [AFS3-std] Call for nomination for the position of AFS3-standardization co-chair In-Reply-To: <4E429CF4.5060705@secure-endpoints.com> References: <562730635.18.1312985402484.JavaMail.root@thunderbeast.private.linuxbox.com> <4E429CF4.5060705@secure-endpoints.com> Message-ID: <1313183337.3168.275.camel@destiny.pc.cs.cmu.edu> On Wed, 2011-08-10 at 11:00 -0400, Jeffrey Altman wrote: > On 8/10/2011 10:10 AM, Matt W. Benjamin wrote: > > Second. > > > > ----- "Douglas E. Engert" wrote: > > > >> I (as a group member, not as co-chair) would like to place in > >> nomination > >> for the co-chair of the AFS3-standardization group, Jeffrey > >> Hutzelman. > >> > >> Jeff's IETF experiences, knowledge of AFS, and > >> organizations skills make him an ideal candidate for the position. Accept. > I believe that Jeff would make an excellent chair (if he has time) but > would prefer that the Chair not also be a registrar. I'd very much like to take a -- I was going to say "less active", but I really mean more like "less blocking" -- role in the registrar process. We actually have other registrars; perhaps if we can get them truly spun up to the point where they are handling day-to-day requests, such things can actually be handled day-to-day. That said, I don't think there's a strong conflict here; neither chairs nor registrars are intended as a check on the power of the other. -- Jeff From matt@linuxbox.com Sat Aug 13 01:03:09 2011 From: matt@linuxbox.com (Matt W. Benjamin) Date: Fri, 12 Aug 2011 20:03:09 -0400 (EDT) Subject: [AFS3-std] Re: Call for nomination for the position of AFS3-standardization co-chair In-Reply-To: <20110812113102.6efde0c0.adeason@sinenomine.net> Message-ID: <1764277117.94.1313193789600.JavaMail.root@thunderbeast.private.linuxbox.com> Hi, I will second this, I assume it means Mike is a volunteer. Matt ----- "Andrew Deason" wrote: > I nominate Mike Meffie for co-chair of the AFS3 standardization > group. > > -- > Andrew Deason > adeason@sinenomine.net > _______________________________________________ > AFS3-standardization mailing list > AFS3-standardization@openafs.org > http://lists.openafs.org/mailman/listinfo/afs3-standardization -- Matt Benjamin The Linux Box 206 South Fifth Ave. Suite 150 Ann Arbor, MI 48104 http://linuxbox.com tel. 734-761-4689 fax. 734-769-8938 cel. 734-216-5309 From deengert@anl.gov Tue Aug 16 15:09:01 2011 From: deengert@anl.gov (Douglas E. Engert) Date: Tue, 16 Aug 2011 09:09:01 -0500 Subject: [AFS3-std] Fwd: Re: [rfc-ise] AFS3 Standardization and Independent Submissions Message-ID: <4E4A79FD.2000808@anl.gov> Our first draft is moving through the IETF Independent Submission Process= , and is now waiting for the author. As far as I know, the two other reviewers have not sent in their reviews. and it would be good have have all the reviews in before submitting a new= draft. -------- Original Message -------- Subject: Re: [rfc-ise] AFS3 Standardization and Independent Submissions Date: Sat, 13 Aug 2011 17:15:07 -0700 From: Nevil Brownlee Organization: Independent Stream To: Derrick Brashear CC: ISE , Hartmut Reuter , "D= ouglas E. Engert" Hi Derrick: Henry Hotz has sent me the appended review of your draft, so I've changed its state to ISR-AUTH. Would you please consider his comments, and publi= sh a new revision that addresses them. I'm still waiting for reviews from Simon Wilkinson and Jeff Altman, I'll prod them now! Cheers, Nevil On 08/01/2011 06:21 PM, Henry B. Hotz wrote: > I've looked at and it is generally fine per-se as to content. > > What I see as significant problems are historical artifacts of the stan= dardization process. This document updates a protocol that does not have= a pre-existing standard description. Consequently, there are a number o= f things which are referenced, but not defined. > > The biggie is the Rx protocol itself. The standard reference for that = is Ed Zayas' "AFS-3 Programmer=92s Reference: Specification for the Rx Re= mote Procedure Call Facility", Version 1.2 of 28 August 1991. I don't kn= ow if that should be a normative or informative reference. I'm inclined = to say informative since it isn't a standards document and wasn't even re= ally binding on Transarc when they put it out. > > That document appears to define everything which I had marked as needin= g definition when I read the draft. > > The following comments are just nits: > > An informative reference to "AFS-3 Programmer=92s Reference: Architectu= ral Overview" might also be useful, but not necessary. (It's referenced = by the Rx doc anyway.) > > Section 6 makes no mention of how an entity is authenticated. Not sure= it needs to, but I felt funny about it. > > The sentence "It is expected. . ." near the top of page 6 seems unclear= to me. More generally the language concerning how names are to be compa= red stays strictly to what the GSSAPI standards say. Speaking from exper= ience people violate the "MUST NOT" because they need to deal with case-f= olding caused by Microsoft Active Directory. I wish I had some standards= -confoming procedure which also worked with AD without deployment convent= ions or other presumptions, but I don't. Absent such a thing I can't sug= gest (or even ask for) changes, but I could wish for some language that b= etter reflected practical necessity. > > The PrCapabilities line near the top of page 7 should be indented one m= ore level. > > > On Jun 1, 2011, at 7:00 PM, Nevil Brownlee wrote: > >> >> Hi Henry: >> >> It's been about three weeks since you volunteered to review >> the draft: draft-brashear-afs3-pts-extended-names >> >> Can you estimate when you'll be able to send me the review, >> please? >> >> Cheers, Nevil >> >> >> On 9/05/11 12:26 PM, Jeffrey Altman wrote: >>> Nevil: >>> >>> Both Simon and I will do so. >>> >>> Thanks. >>> >>> Jeffrey Altman >>> >>> >>> On 5/8/2011 6:45 PM, Nevil Brownlee wrote: >>>> >>>> Hi Douglas: >>>> >>>> Yes, you've defined 'independent reviewer' correctly. >>>> >>>> Two reviews would be enough, that would be Henry (not involved >>>> in AFS3 efforts) and one other - Simon and Jeff, could you please >>>> decide which of you will do it? (Of course, if you'd both like to, >>>> that would be fine too). >>>> >>>> Here's the note I usually send to prospective reviewers: >>>> >>>> "would you be prepared to do a more detailed review, with two >>>> parts: >>>> a) Comments for the Authors >>>> Reasons for rejection or suggestions for improvements. >>>> These will be returned to authors (or you may wish to have >>>> email discussions directly with authors). Could they also >>>> be published on the Independent Submissions web site, >>>> either as public reviews or as anonymous reviews? >>>> b) Comments for the Independent Submissions Editor >>>> These are advice to the ISE, and will not be published." >>>> >>>> Cheers, Nevil >> >> -- >> Nevil Brownlee (ISE), rfc-ise@rfc-editor.org > > ------------------------------------------------------ > The opinions expressed in this message are mine, > not those of Caltech, JPL, NASA, or the US Government. > Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu > > > --=20 Nevil Brownlee (ISE), rfc-ise@rfc-editor.org From mmeffie@sinenomine.net Tue Aug 16 17:40:41 2011 From: mmeffie@sinenomine.net (Michael Meffie) Date: Tue, 16 Aug 2011 12:40:41 -0400 Subject: [AFS3-std] Re: Call for nomination for the position of AFS3-standardization co-chair In-Reply-To: <1764277117.94.1313193789600.JavaMail.root@thunderbeast.private.linuxbox.com> References: <1764277117.94.1313193789600.JavaMail.root@thunderbeast.private.linuxbox.com> Message-ID: <4E4A9D89.50600@sinenomine.net> Matt W. Benjamin wrote: > Hi, > > I will second this, I assume it means Mike is a volunteer. Yes, thank you. I do accept the nomination. Mike -- From deengert@anl.gov Wed Aug 17 19:55:01 2011 From: deengert@anl.gov (Douglas E. Engert) Date: Wed, 17 Aug 2011 13:55:01 -0500 Subject: Fwd: [AFS3-std] Call for nomination for the position of AFS3-standardization co-chair Message-ID: <4E4C0E85.90908@anl.gov> Today is the day to announce the nominations. But I am having problems getting in touch with our co-chair, Hartmut. The co-chairs have to agree on the nominations, and count the votes. I have not heard from him since March. I have a note into 3 contacts and the secretaries at rzg.mpg.de to see if they know anything. (They may not see the note till tomorrow.) Has anyone heard anything? (It could just be August is vacation time for many of us, and in the future we should consider moving back the elections till a month or two.) -------- Original Message -------- Subject: [AFS3-std] Call for nomination for the position of AFS3-standardization co-chair Date: Tue, 02 Aug 2011 11:26:34 -0500 From: Douglas E. Engert To: afs3-standardization@openafs.org CC: Hartmut Reuter , "Douglas E. Engert" http://tools.ietf.org/id/draft-wilkinson-afs3-standardisation-00.txt defines our election procedures to elect a co-chair. It is my position that is up for election, as I have the one year term. Hartmut Reuter is the other co-chair with the 2 year term, due to expire next year. Schedule: Nominations open 8/2 - 8/16 Announcement of nominations 8/17 Voting 8-17 - 8/31 Election results 9/7 Please read section 2.2.2 as to who can be nominated, and who can vote. Send nominations to Hartmut and myself as the vote takers, and we can contact the potential nominees to make sure they are willing to serve. As Jeff points out: > The subscriber list is not public; however, any subscriber can obtain a > copy by filling in his username and password near the bottom of the page > at https://lists.openafs.org/mailman/listinfo/afs3-standardization and > selecting "Visit Subscriber List". Of course, that's as of today. To > build a voter list, you also need to know that there have been no new > subscribers and no one has unsubscribed since April 25, before the start > of the eligibility period. (You can also get your password sent to you with the "Edit Options") -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 _______________________________________________ AFS3-standardization mailing list AFS3-standardization@openafs.org http://lists.openafs.org/mailman/listinfo/afs3-standardization From jaltman@secure-endpoints.com Thu Aug 18 02:46:45 2011 From: jaltman@secure-endpoints.com (Jeffrey Altman) Date: Wed, 17 Aug 2011 21:46:45 -0400 Subject: [AFS3-std] Re: A call for consensus on draft-deason-afs3-type-time-02 In-Reply-To: <87k4any967.fsf@windlord.stanford.edu> References: <20110728135500.76B9ED@grand.central.org> <4E31776B.1040007@odu.edu> <87ei19yma5.fsf@windlord.stanford.edu> <20110729161932.18bc0ced.adeason@sinenomine.net> <87fwlotw4u.fsf@windlord.stanford.edu> <20110808123258.59cc0539.adeason@sinenomine.net> <8762m7ztbg.fsf@windlord.stanford.edu> <20110808125857.a055922a.adeason@sinenomine.net> <87k4any967.fsf@windlord.stanford.edu> Message-ID: <4E4C6F05.2070701@secure-endpoints.com> This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig960E6E28E0B52C10FA2FA539 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I came across this today which might be of interest: http://data.iers.org/products/16/14844/orig/bulletinc-042.txt Quoting: "IMPORTANT: After years of discussions, a proposal to fundamentally redefine UTC will come to a conclusive vote in January 2012 at the ITU-R in Geneva. "This proposal would halt the intercalary adjustments known as leap seconds that maintain UTC as a form of Universal Time." If the proposal is approved it the definition would change in five years from the vote. Our input will be accepted on the subject until the end of August. There are some interesting papers linked from the questionnaire. http://hpiers.obspm.fr/eop-pc/index.php?index=3Dquestionnaire --------------enig960E6E28E0B52C10FA2FA539 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iQEcBAEBAgAGBQJOTG8IAAoJENxm1CNJffh4YwoH+gLXPdKaRz766xaAh+8gt6J8 sYjHtmMlBr5PWOaPMBi5LUS/QAXTyhZS/EfyxMang48B/ByM44h07nhtXoe+qW9f xk9s0+s3UnPbjpw3+USi9LoeBgAW2x+LVMpL76be9DBM+iTQ2VQT0KrY9cu7Jy+v mGkLWImwfVkGUQczUdvzKNA1oyAm1VdJuYhOFx7meLK3HBmmJL4wSDizb6HiU7Ze s5tp1NLMSctvTJItRSXb9OebXQEEzlSqyVjG1VXOk1GSaGX7sExPZT3fDc//NcV4 GeeiqaUL4eonGcPoKTYn+bBtaXRMZlJKYrUDTolPZ0b4MophVkmr5uA1bmm+GRU= =txEM -----END PGP SIGNATURE----- --------------enig960E6E28E0B52C10FA2FA539-- From reuter@rzg.mpg.de Thu Aug 18 13:26:53 2011 From: reuter@rzg.mpg.de (Hartmut Reuter) Date: Thu, 18 Aug 2011 14:26:53 +0200 Subject: Fwd: [AFS3-std] Call for nomination for the position of AFS3-standardization co-chair In-Reply-To: <4E4C0E85.90908@anl.gov> References: <4E4C0E85.90908@anl.gov> Message-ID: <4E4D050D.2050201@rzg.mpg.de> Douglas E. Engert wrote: > Today is the day to announce the nominations. But I am having > problems getting in touch with our co-chair, Hartmut. The > co-chairs have to agree on the nominations, and count the votes. > > I have not heard from him since March. I have a note into > 3 contacts and the secretaries at rzg.mpg.de to see if > they know anything. (They may not see the note till tomorrow.) > > Has anyone heard anything? > > (It could just be August is vacation time for many of us, and > in the future we should consider moving back the elections > till a month or two.) > Doug, sorry for the delay, I was in holidays without access to my mail, but now I am back. I have now followed the last weeks of the mailing list and it seems to me that there are only three nominations: Kim Kimball Jeffrey Hutzelman Mike Meffie where Kim still hasn't replied to the question if he would accept his nomination. So now we either could follow strictly Simon Wilkinson's proposal and start the voting with two candidates or we could do it less strictly and wait for an answer of Kim before starting the voting. What do you prefer, Doug? I am open for both ways. Hartmut > > -------- Original Message -------- > Subject: [AFS3-std] Call for nomination for the position of > AFS3-standardization co-chair > Date: Tue, 02 Aug 2011 11:26:34 -0500 > From: Douglas E. Engert > To: afs3-standardization@openafs.org > CC: Hartmut Reuter , "Douglas E. Engert" > > > http://tools.ietf.org/id/draft-wilkinson-afs3-standardisation-00.txt > > defines our election procedures to elect a co-chair. It is my position > that is up for election, as I have the one year term. Hartmut Reuter > is the other co-chair with the 2 year term, due to expire next year. > > Schedule: > Nominations open 8/2 - 8/16 > Announcement of nominations 8/17 > Voting 8-17 - 8/31 > Election results 9/7 > > Please read section 2.2.2 as to who can be nominated, and who can vote. > > Send nominations to Hartmut and myself as the vote takers, and we can > contact the potential nominees to make sure they are willing to serve. > > As Jeff points out: >> The subscriber list is not public; however, any subscriber can obtain a >> copy by filling in his username and password near the bottom of the page >> at https://lists.openafs.org/mailman/listinfo/afs3-standardization and >> selecting "Visit Subscriber List". Of course, that's as of today. To >> build a voter list, you also need to know that there have been no new >> subscribers and no one has unsubscribed since April 25, before the start >> of the eligibility period. > > (You can also get your password sent to you with the "Edit Options") > -- ----------------------------------------------------------------- Hartmut Reuter e-mail reuter@rzg.mpg.de phone +49-89-3299-1328 fax +49-89-3299-1301 RZG (Rechenzentrum Garching) web http://www.rzg.mpg.de/~hwr Computing Center of the Max-Planck-Gesellschaft (MPG) and the Institut fuer Plasmaphysik (IPP) ----------------------------------------------------------------- From deengert@anl.gov Thu Aug 18 15:18:24 2011 From: deengert@anl.gov (Douglas E. Engert) Date: Thu, 18 Aug 2011 09:18:24 -0500 Subject: [AFS3-std] Voting for the position of AFS3-standardization co-chair Message-ID: <4E4D1F30.10003@anl.gov> http://tools.ietf.org/id/draft-wilkinson-afs3-standardisation-00.txt defines our election procedures to elect a co-chair for a 2 year term starting October 1. In the option of the co-chairs we have two candidates: Jeffrey Hutzelman Mike Meffie Jeff was nominated by Doug Engert and seconded by Matt W. Benjamin. Mike was nominated by Andrew Deason and seconded by Matt Benjamin. I am revising the schedule so voting starts today, and and on September 1. Schedule: Nominations open 8/2 - 8/16 Announcement of nominations 8/18 * revised Voting 8-18 - 9/1 * revised Election results 9/7 Please read section 2.2.2 as to who can vote. Send votes to Hartmut and myself as the vote takers, *NOT* to the list. Please use the subject of this email for voting, you can reply to it, but *NOT* to the full list. -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 _______________________________________________ AFS3-standardization mailing list AFS3-standardization@openafs.org http://lists.openafs.org/mailman/listinfo/afs3-standardization From simon@sxw.org.uk Thu Aug 18 15:30:02 2011 From: simon@sxw.org.uk (Simon Wilkinson) Date: Thu, 18 Aug 2011 15:30:02 +0100 Subject: [AFS3-std] Voting for the position of AFS3-standardization co-chair In-Reply-To: <4E4D1F30.10003@anl.gov> References: <4E4D1F30.10003@anl.gov> Message-ID: <9CDA9B32-7881-4404-B5B7-CDE86CCF82F8@sxw.org.uk> As an elector, it would help me in casting my vote if the candidates = would be prepared to say something on the list about their vision for = the standardisation process, what time they are prepared to devote to = the job, and how they think we can best move things forwards. Thanks, Simon. From dboyes@sinenomine.net Thu Aug 18 18:20:24 2011 From: dboyes@sinenomine.net (David Boyes) Date: Thu, 18 Aug 2011 12:20:24 -0500 Subject: [AFS3-std] Voting for the position of AFS3-standardization co-chair In-Reply-To: <9CDA9B32-7881-4404-B5B7-CDE86CCF82F8@sxw.org.uk> References: <4E4D1F30.10003@anl.gov> <9CDA9B32-7881-4404-B5B7-CDE86CCF82F8@sxw.org.uk> Message-ID: > As an elector, it would help me in casting my vote if the candidates woul= d be > prepared to say something on the list about their vision for the > standardisation process, what time they are prepared to devote to the job= , > and how they think we can best move things forwards. While an excellent idea, it's not in the process right now. Since we have a= lready started the voting, shouldn't we postpone introducing this until nex= t time (and put this in the charter doc)? -- db From jaltman@secure-endpoints.com Thu Aug 18 18:28:01 2011 From: jaltman@secure-endpoints.com (Jeffrey Altman) Date: Thu, 18 Aug 2011 13:28:01 -0400 Subject: [AFS3-std] Voting for the position of AFS3-standardization co-chair In-Reply-To: References: <4E4D1F30.10003@anl.gov> <9CDA9B32-7881-4404-B5B7-CDE86CCF82F8@sxw.org.uk> Message-ID: <4E4D4BA1.8000809@secure-endpoints.com> This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig8FEAB52BF40AA5AACDC0015E Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 8/18/2011 1:20 PM, David Boyes wrote: >> As an elector, it would help me in casting my vote if the candidates w= ould be >> prepared to say something on the list about their vision for the >> standardisation process, what time they are prepared to devote to the = job, >> and how they think we can best move things forwards. >=20 > While an excellent idea, it's not in the process right now. Since we ha= ve already started the voting, shouldn't we postpone introducing this unt= il next time (and put this in the charter doc)? >=20 > -- db I see no reason why people who are running for an office should feel it within their own powers to communicate with those they are intending to serve. A failure to respond to a request from the community is an indication to me that I shouldn't vote for the unresponsive nominee. It has nothing to do with what is or is not required by the process. Jeffrey Altman --------------enig8FEAB52BF40AA5AACDC0015E Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iQEcBAEBAgAGBQJOTUukAAoJENxm1CNJffh45ngH/3X9SN15SrE6MsBoO2ogdT6x OFHIdXFtOIAC2rHsea1BYBbOfr6e7j//sTvjoTwoQXJDTOa6od2qHy3lh8MI2n/P uaUf/WtsgP9Ad5Hx73oNwSzIUG6IL68j3G/9x1tRUbWgktBUGNo0DKJhvMDB7ZGr F0aQqAyNV8v9gEN8S4i3xjBl1Khk0sJ5ECBZxryUXEsXe/MreVHhntKV7kAe19BW fnjOh0noa1jA1VJYXTT29YrgPBc2lfjM5dNXHmaVefWul3Xi7XY3HSaJvDEQQ1WK FWYIjmlfd1qXjybae1duFODOjQb2Cnr8jvsHBgRhB0xjTXiIrNu2xYYC2swd/yw= =3+Iy -----END PGP SIGNATURE----- --------------enig8FEAB52BF40AA5AACDC0015E-- From dboyes@sinenomine.net Thu Aug 18 18:38:48 2011 From: dboyes@sinenomine.net (David Boyes) Date: Thu, 18 Aug 2011 12:38:48 -0500 Subject: [AFS3-std] Voting for the position of AFS3-standardization co-chair In-Reply-To: <4E4D4BA1.8000809@secure-endpoints.com> References: <4E4D1F30.10003@anl.gov> <9CDA9B32-7881-4404-B5B7-CDE86CCF82F8@sxw.org.uk> <4E4D4BA1.8000809@secure-endpoints.com> Message-ID: PiBBIGZhaWx1cmUgdG8gcmVzcG9uZCB0byBhIHJlcXVlc3QgZnJvbSB0aGUgY29tbXVuaXR5IGlz IGFuIGluZGljYXRpb24gdG8gbWUNCj4gdGhhdCBJIHNob3VsZG4ndCB2b3RlIGZvciB0aGUgdW5y ZXNwb25zaXZlIG5vbWluZWUuICBJdCBoYXMgbm90aGluZyB0byBkbyB3aXRoDQo+IHdoYXQgaXMg b3IgaXMgbm90IHJlcXVpcmVkIGJ5IHRoZSBwcm9jZXNzLg0KDQpJIGRpc2FncmVlLiBXZSdyZSBj aGFuZ2luZyB0aGUgcnVsZXMgbWlkLXN0cmVhbS4gDQoNClJpZ2h0IG5vdywgdGhlcmUgaXMgbm8g cmVxdWlyZW1lbnQgZm9yIGFueW9uZSB0byBwcm92aWRlIGEgc3RhdGVtZW50LiBJZiBzb21lb25l IGRvZXMsIHRoZW4gZ29vZCBmb3IgdGhlbSwgYnV0IHdlIHNob3VsZG4ndCBwZW5hbGl6ZSBwZW9w bGUgZm9yIG5vdCBtYWtpbmcgb25lIGlmIGl0IGlzbid0IHJlcXVpcmVkIGJ5IHRoZSBwcm9jZXNz LiBJdCdzIG5vdCBhIGZhaXIgZXZhbHVhdGlvbiBpZiBldmVyeW9uZSBkb2Vzbid0IGhhdmUgdG8g cGxheSBieSB0aGUgc2FtZSBydWxlcy4gDQpFaXRoZXIgbWFrZSBpdCByZXF1aXJlZCBmb3IgZXZl cnlvbmUsIG9yIGRvbid0IGRvIGl0IChmb3IgdGhpcyB0aW1lKS4gDQoNCi0tIGRiDQoNCg== From adeason@sinenomine.net Thu Aug 18 18:49:03 2011 From: adeason@sinenomine.net (Andrew Deason) Date: Thu, 18 Aug 2011 13:49:03 -0400 Subject: [AFS3-std] Re: Voting for the position of AFS3-standardization co-chair References: <4E4D1F30.10003@anl.gov> <9CDA9B32-7881-4404-B5B7-CDE86CCF82F8@sxw.org.uk> <4E4D4BA1.8000809@secure-endpoints.com> Message-ID: <20110818134903.a314437f.adeason@sinenomine.net> On Thu, 18 Aug 2011 12:38:48 -0500 David Boyes wrote: > > A failure to respond to a request from the community is an > > indication to me that I shouldn't vote for the unresponsive nominee. > > It has nothing to do with what is or is not required by the process. > > I disagree. We're changing the rules mid-stream. > > Right now, there is no requirement for anyone to provide a statement. > If someone does, then good for them, but we shouldn't penalize people > for not making one if it isn't required by the process. The only "penalty" is that Jeff won't vote for them; nowhere do I see that Jeff is suggesting that such candidates would be disqualified or anything like that. Jeff is just expressing a desire as a voter, as far as I can read. It seems good that voters express such opinions, so candidates know what the voters are specifically looking for, if anything. I don't envision myself caring about position statements, but if Jeff does, then... good for him. -- Andrew Deason adeason@sinenomine.net From dboyes@sinenomine.net Thu Aug 18 18:53:43 2011 From: dboyes@sinenomine.net (David Boyes) Date: Thu, 18 Aug 2011 12:53:43 -0500 Subject: [AFS3-std] Re: Voting for the position of AFS3-standardization co-chair In-Reply-To: <20110818134903.a314437f.adeason@sinenomine.net> References: <4E4D1F30.10003@anl.gov> <9CDA9B32-7881-4404-B5B7-CDE86CCF82F8@sxw.org.uk> <4E4D4BA1.8000809@secure-endpoints.com> <20110818134903.a314437f.adeason@sinenomine.net> Message-ID: > The only "penalty" is that Jeff won't vote for them; nowhere do I see tha= t > Jeff is suggesting that such candidates would be disqualified or anything= like > that. Jeff is just expressing a desire as a voter, as far as I can read. Which prima facie gives the people who do supply a statement an advantage i= n that at least one voter will not vote for a candidate that does not suppl= y a statement.=20 > It seems > good that voters express such opinions, so candidates know what the voter= s > are specifically looking for, if anything. Agreed. But then all candidates should supply them.=20 =20 > I don't envision myself caring about position statements, but if Jeff doe= s, > then... good for him. I would like them too. But I want them from all candidates so that I'm comp= aring apples to apples, and that every candidate has an equal probability o= f receiving votes from all the electors.=20 From rra@stanford.edu Thu Aug 18 18:57:07 2011 From: rra@stanford.edu (Russ Allbery) Date: Thu, 18 Aug 2011 10:57:07 -0700 Subject: [AFS3-std] Re: Voting for the position of AFS3-standardization co-chair In-Reply-To: (David Boyes's message of "Thu, 18 Aug 2011 12:53:43 -0500") References: <4E4D1F30.10003@anl.gov> <9CDA9B32-7881-4404-B5B7-CDE86CCF82F8@sxw.org.uk> <4E4D4BA1.8000809@secure-endpoints.com> <20110818134903.a314437f.adeason@sinenomine.net> Message-ID: <87aab6bo24.fsf@windlord.stanford.edu> David Boyes writes: > I would like them too. But I want them from all candidates so that I'm > comparing apples to apples, and that every candidate has an equal > probability of receiving votes from all the electors. You are free to reflect that desire in the way that you vote, in the same way that others are free to reflect their desires for statements in the way that they vote. The rules, so far as I know, don't put any restrictions on what factors influence the votes of the people who are eligible to vote. I suspect we've already exerted more effort arguing about this than it really warranted. -- Russ Allbery (rra@stanford.edu) From adeason@sinenomine.net Thu Aug 18 19:02:23 2011 From: adeason@sinenomine.net (Andrew Deason) Date: Thu, 18 Aug 2011 14:02:23 -0400 Subject: [AFS3-std] Re: Voting for the position of AFS3-standardization co-chair References: <4E4D1F30.10003@anl.gov> <9CDA9B32-7881-4404-B5B7-CDE86CCF82F8@sxw.org.uk> <4E4D4BA1.8000809@secure-endpoints.com> <20110818134903.a314437f.adeason@sinenomine.net> Message-ID: <20110818140223.c5382fd3.adeason@sinenomine.net> On Thu, 18 Aug 2011 12:53:43 -0500 David Boyes wrote: > > I don't envision myself caring about position statements, but if > > Jeff does, then... good for him. > > I would like them too. But I want them from all candidates so that I'm > comparing apples to apples, and that every candidate has an equal > probability of receiving votes from all the electors. I'm not sure what you are suggesting? I think the only request was that everyone does send such a statement. If they don't send one... nothing happens. I'm not sure if you are suggesting that such statements are _required_ (those that don't send one are disqualified), or that nominees _cannot_ send such statements. Both of those sound like rule changes to me moreso than the original requests, but perhaps I am drastically misreading you. If this is just your expression of a voter opinion, then... okay. -- Andrew Deason adeason@sinenomine.net From deengert@anl.gov Thu Aug 18 19:12:13 2011 From: deengert@anl.gov (Douglas E. Engert) Date: Thu, 18 Aug 2011 13:12:13 -0500 Subject: [AFS3-std] Re: Voting for the position of AFS3-standardization co-chair In-Reply-To: <87aab6bo24.fsf@windlord.stanford.edu> References: <4E4D1F30.10003@anl.gov> <9CDA9B32-7881-4404-B5B7-CDE86CCF82F8@sxw.org.uk> <4E4D4BA1.8000809@secure-endpoints.com> <20110818134903.a314437f.adeason@sinenomine.net> <87aab6bo24.fsf@windlord.stanford.edu> Message-ID: <4E4D55FD.8050102@anl.gov> As a co-chair, I see no problem with candidates making statements. On 8/18/2011 12:57 PM, Russ Allbery wrote: > David Boyes writes: > >> I would like them too. But I want them from all candidates so that I'm >> comparing apples to apples, and that every candidate has an equal >> probability of receiving votes from all the electors. > > You are free to reflect that desire in the way that you vote, in the same > way that others are free to reflect their desires for statements in the > way that they vote. The rules, so far as I know, don't put any > restrictions on what factors influence the votes of the people who are > eligible to vote. > > I suspect we've already exerted more effort arguing about this than it > really warranted. > -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From dboyes@sinenomine.net Thu Aug 18 19:15:35 2011 From: dboyes@sinenomine.net (David Boyes) Date: Thu, 18 Aug 2011 13:15:35 -0500 Subject: [AFS3-std] Re: Voting for the position of AFS3-standardization co-chair In-Reply-To: <20110818140223.c5382fd3.adeason@sinenomine.net> References: <4E4D1F30.10003@anl.gov> <9CDA9B32-7881-4404-B5B7-CDE86CCF82F8@sxw.org.uk> <4E4D4BA1.8000809@secure-endpoints.com> <20110818134903.a314437f.adeason@sinenomine.net> <20110818140223.c5382fd3.adeason@sinenomine.net> Message-ID: > I'm not sure what you are suggesting? I am suggesting that in the future, the process be changed to require a sta= tement like the one Simon requested from all candidates. I am also suggesti= ng that while it would be nice to have that for this election voluntarily, = not having it should not be a valid basis for rejecting a candidate for the= current election, since the request occurred after the official start of t= he voting period.=20 I don't have any problem with someone providing a statement. I do have a pr= oblem with people stating that they will reject out of hand a candidate tha= t does not provide one if the request was not present at the start of votin= g.=20 > I'm not sure if you are suggesting that such statements are _required_ > (those that don't send one are disqualified), or that nominees _cannot_ s= end > such statements. Both of those sound like rule changes to me moreso than > the original requests, but perhaps I am drastically misreading you. See above. I would like to see evidence that a candidate has thought about = the long-term process and what they intend to do as chair.=20 From mmeffie@sinenomine.net Thu Aug 18 19:36:59 2011 From: mmeffie@sinenomine.net (Michael Meffie) Date: Thu, 18 Aug 2011 14:36:59 -0400 Subject: [AFS3-std] Voting for the position of AFS3-standardization co-chair In-Reply-To: <9CDA9B32-7881-4404-B5B7-CDE86CCF82F8@sxw.org.uk> References: <4E4D1F30.10003@anl.gov> <9CDA9B32-7881-4404-B5B7-CDE86CCF82F8@sxw.org.uk> Message-ID: <4E4D5BCB.9070604@sinenomine.net> Simon Wilkinson wrote: > As an elector, it would help me in casting my vote if the candidates > would be prepared to say something on the list about their vision for > the standardisation process, what time they are prepared to devote to > the job, and how they think we can best move things forwards. I agree it is a reasonable request, Simon. If I had the opporunity to co-chair the group, firstly I would do my best to provide to the group regular, periodic updates of the work in progress, the status of work in progress, and public and private reminders as needed. I would like to include timelines which should show where we stand on documents to ensure we are moving forward in a timely fashion. I have participated in industry-standard forums in the past, although not related to IETF, and understand the issues of fairness and cooperation which is required to build a consensus. In terms of time, I understand this position will require some time per work week and would be able to dedicate time each week to facilitate the standardization process. Mike -- From gary.buhrmaster@gmail.com Fri Aug 19 07:54:44 2011 From: gary.buhrmaster@gmail.com (Gary Buhrmaster) Date: Thu, 18 Aug 2011 23:54:44 -0700 Subject: [AFS3-std] Re: Voting for the position of AFS3-standardization co-chair In-Reply-To: References: <4E4D1F30.10003@anl.gov> <9CDA9B32-7881-4404-B5B7-CDE86CCF82F8@sxw.org.uk> <4E4D4BA1.8000809@secure-endpoints.com> <20110818134903.a314437f.adeason@sinenomine.net> <20110818140223.c5382fd3.adeason@sinenomine.net> Message-ID: On Thu, Aug 18, 2011 at 11:15, David Boyes wrote: .. > I am suggesting that in the future, the process be changed to require a statement like the one Simon requested from all candidates. In the more formal elections I am familiar with, candidates have the option of offering a statement or to choose to provide none at all. I think that is the appropriate way forward (and the voters will make of those choices by the candidates what they will, as it should be). One alternative might be a (built-in) hold between the candidates being announced and voting beginning to allow the candidates to state their positions on list. Another might be that the chairs ask that as part of the acceptance of the nomination the potential candidate is offered an opportunity to provide a statement that the chair would include in the formal "election has started" email. But that would be for the next election. This election is already in progress. From dboyes@sinenomine.net Fri Aug 19 08:28:58 2011 From: dboyes@sinenomine.net (David Boyes) Date: Fri, 19 Aug 2011 02:28:58 -0500 Subject: [AFS3-std] Re: Voting for the position of AFS3-standardization co-chair In-Reply-To: References: <4E4D1F30.10003@anl.gov> <9CDA9B32-7881-4404-B5B7-CDE86CCF82F8@sxw.org.uk> <4E4D4BA1.8000809@secure-endpoints.com> <20110818134903.a314437f.adeason@sinenomine.net> <20110818140223.c5382fd3.adeason@sinenomine.net> Message-ID: <35BBE9DA-E253-4A01-A02A-B437E3EE6311@sinenomine.net> > One alternative might be a (built-in) hold between > the candidates being announced and voting beginning > to allow the candidates to state their positions on list. > Another might be that the chairs ask that as part > of the acceptance of the nomination the potential > candidate is offered an opportunity to provide a > statement that the chair would include in the > formal "election has started" email. Either of these options seem reasonable for next time. I do still think tha= t if we use them, we should officially add them to the process.= From adeason@sinenomine.net Fri Aug 26 23:29:32 2011 From: adeason@sinenomine.net (Andrew Deason) Date: Fri, 26 Aug 2011 17:29:32 -0500 Subject: [AFS3-std] New version of the 64-bit time I-D (-03) Message-ID: <20110826172932.c2ec883f.adeason@sinenomine.net> draft-deason-afs3-type-time-03 has been posted and is available at This changes the epoch of the absolute time types to the Unix epoch, and changes the names to include '64' in them. Some discussion about differing time granularities and pre-UTC dates has been added. There are a lot of changes between -02 and -03, most of which are just to accommodate the changes in epoch and type names, and other minor stuff like that. While I appreciate feedback on anything in the document, sections 5 (Resolution Limitations) and 6 (Times Before UTC) are completely new, and contain more substantive new text than any other changes. So, if you don't want to read the whole thing again, I'd urge you to at least read those two sections. -- Andrew Deason adeason@sinenomine.net From deengert@anl.gov Mon Aug 29 14:24:53 2011 From: deengert@anl.gov (Douglas E. Engert) Date: Mon, 29 Aug 2011 08:24:53 -0500 Subject: Fwd: [AFS3-std] Voting for the position of AFS3-standardization co-chair Message-ID: <4E5B9325.9020507@anl.gov> This is a reminder, your votes must be in by the end of Thursday 9/1. -------- Original Message -------- Subject: [AFS3-std] Voting for the position of AFS3-standardization co-chair Date: Thu, 18 Aug 2011 09:18:24 -0500 From: Douglas E. Engert To: afs3-standardization@openafs.org CC: Hartmut Reuter , "Douglas E. Engert" http://tools.ietf.org/id/draft-wilkinson-afs3-standardisation-00.txt defines our election procedures to elect a co-chair for a 2 year term starting October 1. In the option of the co-chairs we have two candidates: Jeffrey Hutzelman Mike Meffie Jeff was nominated by Doug Engert and seconded by Matt W. Benjamin. Mike was nominated by Andrew Deason and seconded by Matt Benjamin. I am revising the schedule so voting starts today, and and on September 1. Schedule: Nominations open 8/2 - 8/16 Announcement of nominations 8/18 * revised Voting 8-18 - 9/1 * revised Election results 9/7 Please read section 2.2.2 as to who can vote. Send votes to Hartmut and myself as the vote takers, *NOT* to the list. Please use the subject of this email for voting, you can reply to it, but *NOT* to the full list. -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 _______________________________________________ AFS3-standardization mailing list AFS3-standardization@openafs.org http://lists.openafs.org/mailman/listinfo/afs3-standardization _______________________________________________ AFS3-standardization mailing list AFS3-standardization@openafs.org http://lists.openafs.org/mailman/listinfo/afs3-standardization From deengert@anl.gov Wed Aug 31 21:21:44 2011 From: deengert@anl.gov (Douglas E. Engert) Date: Wed, 31 Aug 2011 15:21:44 -0500 Subject: Fwd: [AFS3-std] Voting for the position of AFS3-standardization co-chair Message-ID: <4E5E97D8.3060204@anl.gov> This is a reminder, you have only one more day to vote. Votes must be received by Thu, 01 Sep 2011 23:59:59 -0500 (CDT) Last year 21 people voted, so far we have received only 10 votes. -------- Original Message -------- Subject: [AFS3-std] Voting for the position of AFS3-standardization co-chair Date: Thu, 18 Aug 2011 09:18:24 -0500 From: Douglas E. Engert To: afs3-standardization@openafs.org CC: Hartmut Reuter , "Douglas E. Engert" http://tools.ietf.org/id/draft-wilkinson-afs3-standardisation-00.txt defines our election procedures to elect a co-chair for a 2 year term starting October 1. In the option of the co-chairs we have two candidates: Jeffrey Hutzelman Mike Meffie Jeff was nominated by Doug Engert and seconded by Matt W. Benjamin. Mike was nominated by Andrew Deason and seconded by Matt Benjamin. I am revising the schedule so voting starts today, and and on September 1. Schedule: Nominations open 8/2 - 8/16 Announcement of nominations 8/18 * revised Voting 8-18 - 9/1 * revised Election results 9/7 Please read section 2.2.2 as to who can vote. Send votes to Hartmut and myself as the vote takers, *NOT* to the list. Please use the subject of this email for voting, you can reply to it, but *NOT* to the full list. -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 _______________________________________________ AFS3-standardization mailing list AFS3-standardization@openafs.org http://lists.openafs.org/mailman/listinfo/afs3-standardization _______________________________________________ AFS3-standardization mailing list AFS3-standardization@openafs.org http://lists.openafs.org/mailman/listinfo/afs3-standardization _______________________________________________ AFS3-standardization mailing list AFS3-standardization@openafs.org http://lists.openafs.org/mailman/listinfo/afs3-standardization From tkeiser@sinenomine.net Mon Aug 1 00:53:40 2011 From: tkeiser@sinenomine.net (Tom Keiser) Date: Sun, 31 Jul 2011 19:53:40 -0400 Subject: [AFS3-std] Re: XDR extensible union type In-Reply-To: <5D0108C15137EC449A517DD8454DE71503041C69F4@34093-MBX-C15.mex07a.mlsrvr.com> References: <5D0108C15137EC449A517DD8454DE71503041C69F4@34093-MBX-C15.mex07a.mlsrvr.com> Message-ID: --0015174483e85c0ec004a9663966 Content-Type: text/plain; charset=ISO-8859-1 I pushed draft-keiser-afs3-xdr-union-03 (incorporating Derrick's grammatical corrections) to the IETF last week. Comments are hereby solicited. http://tools.ietf.org/html/draft-keiser-afs3-xdr-union-03 Cheers, -Tom On Jul 20, 2011 8:46 PM, "Tom Keiser" wrote: > Hi Derrick, > > Thanks very much for the review; I'll incorporate those edits. > > I'd like to publish -03 on Tuesday. If any interested party can find time to send comments by Monday, it would be greatly appreciated. > > Cheers, > > -Tom > > Sent from my phone; please excuse any typographic or grammatical errors. > > -----Original Message----- > From: Derrick Brashear [shadow@gmail.com] > Received: Wednesday, 20 Jul 2011, 9:33am > To: Tom Keiser [tkeiser@sinenomine.net] > Subject: Re: [AFS3-std] Re: XDR extensible union type > > i lie > > "1. Lookup the discriminant" > > I believe that should be, as an operation, "look up" > > > On Wed, Jul 20, 2011 at 9:31 AM, Derrick Brashear wrote: >> 6. AFS Assign Numbers Registrar Considerations >> >> "Assigned" >> >> the actual content is fine and i see no issues. >> >> On Tue, Jul 19, 2011 at 6:02 PM, Tom Keiser wrote: >>> On Jun 20, 2011 2:41 PM, "Tom Keiser" wrote: >>>> Hi all, >>>> >>>> I pushed a new revision of draft-keiser-afs3-xdr-union: >>>> >>>> http://tools.ietf.org/html/draft-keiser-afs3-xdr-union-02 >>>> >>>> This revision incorporates the following two changes: >>>> >>>> * modify section on error handling (3.4.1) to make length mismatches a >>>> fatal error >>>> * add a "use case" section (1.1) to discuss trade-offs associated with >>>> using this type >>>> >>>> Any comments are welcome. >>>> >>>> -Tom >>> >>> This is a second call for review of draft-keiser-afs3-xdr-union-02; all >>> comments are welcome. >>> >>> Cheers, >>> >>> -Tom >> >> >> >> -- >> Derrick >> > > > > -- > Derrick --0015174483e85c0ec004a9663966 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

I pushed draft-keiser-afs3-xdr-union-03 (incorporating Derrick's gra= mmatical corrections) to the IETF last week.=A0 Comments are hereby solicit= ed.

ht= tp://tools.ietf.org/html/draft-keiser-afs3-xdr-union-03

Cheers,

-Tom

On Jul 20, 2011 8:46 PM, "Tom Keiser" = <tkeiser@sinenomine.net>= ; wrote:
> Hi Derrick,
>
> Thanks v= ery much for the review; I'll incorporate those edits.
>
> I'd like to publish -03 on Tuesday. If any interested par= ty can find time to send comments by Monday, it would be greatly appreciate= d.
>
> Cheers,
>
> -Tom
>
> Sent fro= m my phone; please excuse any typographic or grammatical errors.
>
> -----Original Message-----
> From: Derrick Brashear [shadow@gmail.com]
> Received: W= ednesday, 20 Jul 2011, 9:33am
> To: Tom Keiser [tkeiser@sinenomine.net]
> Subject: Re: [AFS3-std] Re: XDR extensible union type
>
>= i lie
>
> "1. Lookup the discriminant"
> > I believe that should be, as an operation, "look up"
>
>
> On Wed, Jul 20, 2011 at 9:31 AM, Derrick Brashear &l= t;shadow@gmail.com> wrote:
&g= t;> 6. AFS Assign Numbers Registrar Considerations
>>
>&= gt; "Assigned"
>>
>> the actual content is fine and i see no issues.
>= ;>
>> On Tue, Jul 19, 2011 at 6:02 PM, Tom Keiser <tkeiser@sinenomine.net> wrote: >>> On Jun 20, 2011 2:41 PM, "Tom Keiser" <tkeiser@sinenomine.net> wrote:
&g= t;>>> Hi all,
>>>>
>>>> I pushed a n= ew revision of draft-keiser-afs3-xdr-union:
>>>>
>>>> http://tools.ietf.org/html/draft-keiser-afs= 3-xdr-union-02
>>>>
>>>> This revision in= corporates the following two changes:
>>>>
>>>> * modify section on error handling (3.= 4.1) to make length mismatches a
>>>> fatal error
>>= ;>> * add a "use case" section (1.1) to discuss trade-offs = associated with
>>>> using this type
>>>>
>>>> An= y comments are welcome.
>>>>
>>>> -Tom
>= ;>>
>>> This is a second call for review of draft-keiser= -afs3-xdr-union-02; all
>>> comments are welcome.
>>>
>>> Cheers,<= br>>>>
>>> -Tom
>>
>>
>>>> --
>> Derrick
>>
>
>
>
> --
> Derrick
--0015174483e85c0ec004a9663966-- From simon@sxw.org.uk Mon Aug 1 18:07:35 2011 From: simon@sxw.org.uk (Simon Wilkinson) Date: Mon, 1 Aug 2011 18:07:35 +0100 Subject: [AFS3-std] Re: A call for consensus on draft-deason-afs3-type-time-02 In-Reply-To: <87fwlotw4u.fsf@windlord.stanford.edu> References: <20110728135500.76B9ED@grand.central.org> <4E31776B.1040007@odu.edu> <87ei19yma5.fsf@windlord.stanford.edu> <20110729161932.18bc0ced.adeason@sinenomine.net> <87fwlotw4u.fsf@windlord.stanford.edu> Message-ID: Given how much of what we want to do depends on defining a new time type, it= would be good to keep up the momentum with this draft. Would those with problems with the current draft be prepared to suggest new w= ording for: a) the epoch value b) the granularity that we could use as a basis for further discussion? It would also be wonder= ful if everyone with an interest in this topic could participate in that dis= cussion, rather than waiting for another last call to raise objections. Thanks, Simon= From rra@stanford.edu Mon Aug 1 18:13:57 2011 From: rra@stanford.edu (Russ Allbery) Date: Mon, 01 Aug 2011 10:13:57 -0700 Subject: [AFS3-std] Re: A call for consensus on draft-deason-afs3-type-time-02 In-Reply-To: (Simon Wilkinson's message of "Mon, 1 Aug 2011 18:07:35 +0100") References: <20110728135500.76B9ED@grand.central.org> <4E31776B.1040007@odu.edu> <87ei19yma5.fsf@windlord.stanford.edu> <20110729161932.18bc0ced.adeason@sinenomine.net> <87fwlotw4u.fsf@windlord.stanford.edu> Message-ID: <87wrex836y.fsf@windlord.stanford.edu> Simon Wilkinson writes: > Would those with problems with the current draft be prepared to suggest > new wording for: > a) the epoch value > b) the granularity > that we could use as a basis for further discussion? It would also be > wonderful if everyone with an interest in this topic could participate > in that discussion, rather than waiting for another last call to raise > objections. As nice as it would be to be able to represent old timestamps in the file system, we've never been able to before (at least consistently), and I think the simplicity benefits for compatibility with current code bases of sticking with the POSIX epoch are substantial. I don't have an opinion on the granularity. For me, the benefits of matching NFS and the POSIX timestamp granularity is fairly evenly balanced against the drawbacks of increasing the size of all of our protocol packets. -- Russ Allbery (rra@stanford.edu) From matt@linuxbox.com Mon Aug 1 18:21:47 2011 From: matt@linuxbox.com (Matt W. Benjamin) Date: Mon, 1 Aug 2011 13:21:47 -0400 (EDT) Subject: [AFS3-std] Re: A call for consensus on draft-deason-afs3-type-time-02 In-Reply-To: <87wrex836y.fsf@windlord.stanford.edu> Message-ID: <159746358.62.1312219307195.JavaMail.root@thunderbeast.private.linuxbox.com> Hi, a) with Russ b) Intuitively I would have voted and would vote for the more NFS, POSIX flavor of timestamp granularity. In prior discussion, that was not the consensus. Matt ----- "Russ Allbery" wrote: > Simon Wilkinson writes: > > > Would those with problems with the current draft be prepared to > suggest > > new wording for: > > > a) the epoch value > > b) the granularity > > As nice as it would be to be able to represent old timestamps in the > file > system, we've never been able to before (at least consistently), and > I > think the simplicity benefits for compatibility with current code > bases of > sticking with the POSIX epoch are substantial. > > I don't have an opinion on the granularity. For me, the benefits of > matching NFS and the POSIX timestamp granularity is fairly evenly > balanced > against the drawbacks of increasing the size of all of our protocol > packets. > -- Matt Benjamin The Linux Box 206 South Fifth Ave. Suite 150 Ann Arbor, MI 48104 http://linuxbox.com tel. 734-761-4689 fax. 734-769-8938 cel. 734-216-5309 From adeason@sinenomine.net Mon Aug 1 18:28:10 2011 From: adeason@sinenomine.net (Andrew Deason) Date: Mon, 1 Aug 2011 12:28:10 -0500 Subject: [AFS3-std] Re: A call for consensus on draft-deason-afs3-type-time-02 References: <20110728135500.76B9ED@grand.central.org> <4E31776B.1040007@odu.edu> <87ei19yma5.fsf@windlord.stanford.edu> <20110729161932.18bc0ced.adeason@sinenomine.net> <87fwlotw4u.fsf@windlord.stanford.edu> Message-ID: <20110801122810.81b1889c.adeason@sinenomine.net> On Mon, 1 Aug 2011 18:07:35 +0100 Simon Wilkinson wrote: > Given how much of what we want to do depends on defining a new time > type, it would be good to keep up the momentum with this draft. > > Would those with problems with the current draft be prepared to > suggest new wording for: > > a) the epoch value I don't think I've heard any significant arguments for keeping the epoch as it exists in the current draft. And since there are issues with the current epoch value that Russ has detailed, it makes sense to me to change it to the posix epoch. I was going to change it unless I heard someone object; I'll propose some new text soon based on Russ' suggestions unless someone else wants to. > b) the granularity This one I still have no idea on. I see reasons for both sides. > that we could use as a basis for further discussion? It would also be > wonderful if everyone with an interest in this topic could participate > in that discussion, rather than waiting for another last call to raise > objections. Most people involved have a lot of deadlines to work with and balance. Right now, the only "deadline" we are given for standards discussion is the last call. If you want to ensure discussion before that point, give another deadline. -- Andrew Deason adeason@sinenomine.net From shadow@gmail.com Mon Aug 1 18:32:46 2011 From: shadow@gmail.com (Derrick Brashear) Date: Mon, 1 Aug 2011 13:32:46 -0400 Subject: [AFS3-std] Re: A call for consensus on draft-deason-afs3-type-time-02 In-Reply-To: <20110801122810.81b1889c.adeason@sinenomine.net> References: <20110728135500.76B9ED@grand.central.org> <4E31776B.1040007@odu.edu> <87ei19yma5.fsf@windlord.stanford.edu> <20110729161932.18bc0ced.adeason@sinenomine.net> <87fwlotw4u.fsf@windlord.stanford.edu> <20110801122810.81b1889c.adeason@sinenomine.net> Message-ID: On Mon, Aug 1, 2011 at 1:28 PM, Andrew Deason wrote: >> b) the granularity > > This one I still have no idea on. I see reasons for both sides. So is there a reason an extended union with the various stamp granularities would be a nonstarter? In particular I'd suggest the draft strongly discourage sending a larger timestamp than actual information supports (e.g. don't use bits to send precision you don't have, rather than trailing-zero-padding a larger than needed number) -- Derrick From jaltman@secure-endpoints.com Mon Aug 1 18:39:35 2011 From: jaltman@secure-endpoints.com (Jeffrey Altman) Date: Mon, 01 Aug 2011 13:39:35 -0400 Subject: [AFS3-std] Re: A call for consensus on draft-deason-afs3-type-time-02 In-Reply-To: <87wrex836y.fsf@windlord.stanford.edu> References: <20110728135500.76B9ED@grand.central.org> <4E31776B.1040007@odu.edu> <87ei19yma5.fsf@windlord.stanford.edu> <20110729161932.18bc0ced.adeason@sinenomine.net> <87fwlotw4u.fsf@windlord.stanford.edu> <87wrex836y.fsf@windlord.stanford.edu> Message-ID: <4E36E4D7.9010308@secure-endpoints.com> This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig4A27C580FE23C3E7E55C905E Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 8/1/2011 1:13 PM, Russ Allbery wrote: > As nice as it would be to be able to represent old timestamps in the fi= le > system, we've never been able to before (at least consistently), and I > think the simplicity benefits for compatibility with current code bases= of > sticking with the POSIX epoch are substantial. > > I don't have an opinion on the granularity. For me, the benefits of > matching NFS and the POSIX timestamp granularity is fairly evenly balan= ced > against the drawbacks of increasing the size of all of our protocol > packets. I have a strong desire to ensure that everything that can be represented in an NTFS file system can be represented in AFS. I don't care if the epoch is the same or if the granularity is better than 100ns or not. I am concerned about the size of status structures given how frequently they are sent and because the size of the status structure determines how many FIDs can be specified in a single Bulk Status request. It would be nice if we could have some form of compressed time representation that only sent the required number of bits necessary to represent the required granularity. Jeffrey Altman --------------enig4A27C580FE23C3E7E55C905E Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iQEcBAEBAgAGBQJONuTdAAoJENxm1CNJffh4/1EH/2edEyuNmABtPOma63yPvItC dlmgGYHO5YnJyW7dsoPyE4+wtorPCPFpVIriwIyke7eXhBjDHYod0sE+PjMa00US elGszsC+O8YFReJQkvCUo6K82sTNmjIDI95tFtTWPuPM4NDniN7HW2IhjqbIZOX1 pArwMylZD2BUk+GjPbpElgWqQoFhB96pHgmS4UK94brY9wGfjo/geMWgN/kLm5OP pGtiAhj01mDrr5qKYe8l0fQm9EVd2BTB2TI7flshB5foFFx+86LadxQdyhUciDdg W6NHvqbEbDPoHvOqsrHg4bvxYQnsXBkDGsnC2goeZ3B1pMKt466GHoUbBtEAXXU= =EWEN -----END PGP SIGNATURE----- --------------enig4A27C580FE23C3E7E55C905E-- From rra@stanford.edu Mon Aug 1 18:50:51 2011 From: rra@stanford.edu (Russ Allbery) Date: Mon, 01 Aug 2011 10:50:51 -0700 Subject: [AFS3-std] Re: A call for consensus on draft-deason-afs3-type-time-02 In-Reply-To: <4E36E4D7.9010308@secure-endpoints.com> (Jeffrey Altman's message of "Mon, 01 Aug 2011 13:39:35 -0400") References: <20110728135500.76B9ED@grand.central.org> <4E31776B.1040007@odu.edu> <87ei19yma5.fsf@windlord.stanford.edu> <20110729161932.18bc0ced.adeason@sinenomine.net> <87fwlotw4u.fsf@windlord.stanford.edu> <87wrex836y.fsf@windlord.stanford.edu> <4E36E4D7.9010308@secure-endpoints.com> Message-ID: <87fwll81hg.fsf@windlord.stanford.edu> Jeffrey Altman writes: > I have a strong desire to ensure that everything that can be represented > in an NTFS file system can be represented in AFS. Does that include timestamps prior to 1970, just to check? -- Russ Allbery (rra@stanford.edu) From adeason@sinenomine.net Mon Aug 1 18:53:44 2011 From: adeason@sinenomine.net (Andrew Deason) Date: Mon, 1 Aug 2011 12:53:44 -0500 Subject: [AFS3-std] Re: A call for consensus on draft-deason-afs3-type-time-02 References: <20110728135500.76B9ED@grand.central.org> <4E31776B.1040007@odu.edu> <87ei19yma5.fsf@windlord.stanford.edu> <20110729161932.18bc0ced.adeason@sinenomine.net> <87fwlotw4u.fsf@windlord.stanford.edu> <20110801122810.81b1889c.adeason@sinenomine.net> Message-ID: <20110801125344.e9e45873.adeason@sinenomine.net> On Mon, 1 Aug 2011 13:32:46 -0400 Derrick Brashear wrote: > On Mon, Aug 1, 2011 at 1:28 PM, Andrew Deason wrote: > > >> b) the granularity > > > > This one I still have no idea on. I see reasons for both sides. > > So is there a reason an extended union with the various stamp > granularities would be a nonstarter? In particular I'd suggest the > draft strongly discourage > sending a larger timestamp than actual information supports (e.g. > don't use bits to send precision you don't have, rather than > trailing-zero-padding a > larger than needed number) Well, the objection to just having 64-bit seconds and 32-bit nanoseconds is "space", and a union tag is an extra 32 bits... If we had a "100 NS granularity" tag, then we'd have 100-ns granularity in 96 bits, whereas now we could have 1-ns granularity in 96 bits. Unless there's some other scheme you're thinking of that somehow makes this more efficient? I had some kind of variable-length scheme that encoded the granularity in the 'unused' bits of the value for coarser granularities, but I'm pretty sure that only saved space for the *TimeRes types, and doesn't really help for 'plain' times. -- Andrew Deason adeason@sinenomine.net From jaltman@secure-endpoints.com Mon Aug 1 19:01:25 2011 From: jaltman@secure-endpoints.com (Jeffrey Altman) Date: Mon, 01 Aug 2011 14:01:25 -0400 Subject: [AFS3-std] Re: A call for consensus on draft-deason-afs3-type-time-02 In-Reply-To: <87fwll81hg.fsf@windlord.stanford.edu> References: <20110728135500.76B9ED@grand.central.org> <4E31776B.1040007@odu.edu> <87ei19yma5.fsf@windlord.stanford.edu> <20110729161932.18bc0ced.adeason@sinenomine.net> <87fwlotw4u.fsf@windlord.stanford.edu> <87wrex836y.fsf@windlord.stanford.edu> <4E36E4D7.9010308@secure-endpoints.com> <87fwll81hg.fsf@windlord.stanford.edu> Message-ID: <4E36E9F5.9000502@secure-endpoints.com> This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig23F50A5B2A28DAF581F3533F Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 8/1/2011 1:50 PM, Russ Allbery wrote: > Jeffrey Altman writes: >=20 >> I have a strong desire to ensure that everything that can be represent= ed >> in an NTFS file system can be represented in AFS. >=20 > Does that include timestamps prior to 1970, just to check? >=20 Yes. --------------enig23F50A5B2A28DAF581F3533F Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iQEcBAEBAgAGBQJONun2AAoJENxm1CNJffh4mrIIAIEPpQF6ZniJKtOR3Go0RhOo UJihNKxv52kCD9Jsulu+C19n5L0QkqfFqXUSJNtOqU0a7M0rypzhiyOmpdKiboiB st2NhCi50BPkbVq68+GbhzHIZLNEs3aMnV8Xhhl76e9s+rmlXy7G/bY1pMxIWYAn zY58jFCcgeeTHf06qcGsop1VwyQX4Vy/POnbs5+YybtOxTGIvi/awa2YFaqLZeyz pUZe8TgpYR3XODPoc6ykc/SFoD4c+PpToHEXQFHZVWbpDpMIU9M4WmbZESRGObxX 5bqOusZgx7THzk5r5nTc8BWWmp5tnPvALz+MOlHTRvFje99rwQz/Cl+luWDY/ak= =Tflf -----END PGP SIGNATURE----- --------------enig23F50A5B2A28DAF581F3533F-- From rra@stanford.edu Mon Aug 1 19:13:50 2011 From: rra@stanford.edu (Russ Allbery) Date: Mon, 01 Aug 2011 11:13:50 -0700 Subject: [AFS3-std] Re: A call for consensus on draft-deason-afs3-type-time-02 In-Reply-To: <4E36E9F5.9000502@secure-endpoints.com> (Jeffrey Altman's message of "Mon, 01 Aug 2011 14:01:25 -0400") References: <20110728135500.76B9ED@grand.central.org> <4E31776B.1040007@odu.edu> <87ei19yma5.fsf@windlord.stanford.edu> <20110729161932.18bc0ced.adeason@sinenomine.net> <87fwlotw4u.fsf@windlord.stanford.edu> <87wrex836y.fsf@windlord.stanford.edu> <4E36E4D7.9010308@secure-endpoints.com> <87fwll81hg.fsf@windlord.stanford.edu> <4E36E9F5.9000502@secure-endpoints.com> Message-ID: <871ux580f5.fsf@windlord.stanford.edu> Jeffrey Altman writes: > On 8/1/2011 1:50 PM, Russ Allbery wrote: >> Jeffrey Altman writes: >>> I have a strong desire to ensure that everything that can be represented >>> in an NTFS file system can be represented in AFS. >> Does that include timestamps prior to 1970, just to check? > Yes. Okay, so you *do* care about what epoch is used, unless we use a time definition that allows for negative offsets from the epoch. Does Microsoft have documentation for how the Windows epoch deals with Gregorian calendar conversions and leap seconds? -- Russ Allbery (rra@stanford.edu) From shadow@gmail.com Mon Aug 1 19:19:11 2011 From: shadow@gmail.com (Derrick Brashear) Date: Mon, 1 Aug 2011 14:19:11 -0400 Subject: [AFS3-std] Re: A call for consensus on draft-deason-afs3-type-time-02 In-Reply-To: <20110801125344.e9e45873.adeason@sinenomine.net> References: <20110728135500.76B9ED@grand.central.org> <4E31776B.1040007@odu.edu> <87ei19yma5.fsf@windlord.stanford.edu> <20110729161932.18bc0ced.adeason@sinenomine.net> <87fwlotw4u.fsf@windlord.stanford.edu> <20110801122810.81b1889c.adeason@sinenomine.net> <20110801125344.e9e45873.adeason@sinenomine.net> Message-ID: On Mon, Aug 1, 2011 at 1:53 PM, Andrew Deason wrote: > On Mon, 1 Aug 2011 13:32:46 -0400 > Derrick Brashear wrote: > >> On Mon, Aug 1, 2011 at 1:28 PM, Andrew Deason wrote: >> >> >> b) the granularity >> > >> > This one I still have no idea on. I see reasons for both sides. >> >> So is there a reason an extended union with the various stamp >> granularities would be a nonstarter? In particular I'd suggest the >> draft strongly discourage >> sending a larger timestamp than actual information supports (e.g. >> don't use bits to send precision you don't have, rather than >> trailing-zero-padding a >> larger than needed number) > > Well, the objection to just having 64-bit seconds and 32-bit nanoseconds > is "space", and a union tag is an extra 32 bits... If we had a "100 NS > granularity" tag, then we'd have 100-ns granularity in 96 bits, whereas > now we could have 1-ns granularity in 96 bits. Unless there's some other > scheme you're thinking of that somehow makes this more efficient? for the worst case, it's worse. for the best case, it's better. but i suppose it may not be worth it given that the worst case will become more prevalent over time. > I had some kind of variable-length scheme that encoded the granularity > in the 'unused' bits of the value for coarser granularities, but I'm > pretty sure that only saved space for the *TimeRes types, and doesn't > really help for 'plain' times. and those are going to be a majority, i think. -- Derrick From tkeiser@sinenomine.net Mon Aug 1 21:16:44 2011 From: tkeiser@sinenomine.net (Tom Keiser) Date: Mon, 1 Aug 2011 16:16:44 -0400 Subject: [AFS3-std] Re: A call for consensus on draft-deason-afs3-type-time-02 In-Reply-To: <20110801125344.e9e45873.adeason@sinenomine.net> References: <20110728135500.76B9ED@grand.central.org> <4E31776B.1040007@odu.edu> <87ei19yma5.fsf@windlord.stanford.edu> <20110729161932.18bc0ced.adeason@sinenomine.net> <87fwlotw4u.fsf@windlord.stanford.edu> <20110801122810.81b1889c.adeason@sinenomine.net> <20110801125344.e9e45873.adeason@sinenomine.net> Message-ID: On Mon, Aug 1, 2011 at 1:53 PM, Andrew Deason wrote: > On Mon, 1 Aug 2011 13:32:46 -0400 > Derrick Brashear wrote: > >> On Mon, Aug 1, 2011 at 1:28 PM, Andrew Deason wrote: >> >> >> b) the granularity >> > >> > This one I still have no idea on. I see reasons for both sides. >> >> So is there a reason an extended union with the various stamp >> granularities would be a nonstarter? In particular I'd suggest the >> draft strongly discourage >> sending a larger timestamp than actual information supports (e.g. >> don't use bits to send precision you don't have, rather than >> trailing-zero-padding a >> larger than needed number) > > Well, the objection to just having 64-bit seconds and 32-bit nanoseconds > is "space", and a union tag is an extra 32 bits... If we had a "100 NS > granularity" tag, then we'd have 100-ns granularity in 96 bits, whereas > now we could have 1-ns granularity in 96 bits. Unless there's some other > scheme you're thinking of that somehow makes this more efficient? > This is why in Pittsburgh we proposed that overarching structures (e.g., AFSFetchStatus, and AFSStoreStatus) should be wrapped in ext-union, while proscribing the use of union/ext-union for individual members of those structures. As I suggested last Friday, we could define two different AFSFetchStatus/AFSStoreStatus implied legs for now: one with 64-bit time, and a second with 96-bit time (perhaps, we would also want to define a third leg with 32-bit time--given that we're likely to have implementations of the protocol long before server backing stores can handle the increased resolution)... -Tom From deengert@anl.gov Mon Aug 1 21:47:47 2011 From: deengert@anl.gov (Douglas E. Engert) Date: Mon, 01 Aug 2011 15:47:47 -0500 Subject: [AFS3-std] Election Procedure for AFS-3 Working Group Chairs Message-ID: <4E3710F3.3000603@anl.gov> http://tools.ietf.org/id/draft-wilkinson-afs3-standardisation-00.txt Says its time for an election, typically with nominations starting August 1, for 14 days, voting for 14 days, and 7 days to count with the new chair starting on October 1. It is my position that is up for election, as I have the one year term. Hartmut Reuter is the other co-chair with the 2 year term. Please read section 2.2.2 as to who can be nominated, and who can vote. (We will need a list of eligible voters, from the mailman-owner for our list. Once we get that we can start the nomination process, and keep within the guidelines and have a chair by October 1.) -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From jaltman@secure-endpoints.com Mon Aug 1 22:05:36 2011 From: jaltman@secure-endpoints.com (Jeffrey Altman) Date: Mon, 01 Aug 2011 17:05:36 -0400 Subject: [AFS3-std] Re: A call for consensus on draft-deason-afs3-type-time-02 In-Reply-To: <871ux580f5.fsf@windlord.stanford.edu> References: <20110728135500.76B9ED@grand.central.org> <4E31776B.1040007@odu.edu> <87ei19yma5.fsf@windlord.stanford.edu> <20110729161932.18bc0ced.adeason@sinenomine.net> <87fwlotw4u.fsf@windlord.stanford.edu> <87wrex836y.fsf@windlord.stanford.edu> <4E36E4D7.9010308@secure-endpoints.com> <87fwll81hg.fsf@windlord.stanford.edu> <4E36E9F5.9000502@secure-endpoints.com> <871ux580f5.fsf@windlord.stanford.edu> Message-ID: <4E371520.2050905@secure-endpoints.com> This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF4A4B8C5B5CC41684FB59F42 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 8/1/2011 2:13 PM, Russ Allbery wrote: > Okay, so you *do* care about what epoch is used, unless we use a time > definition that allows for negative offsets from the epoch. I am fine with negative offsets from epoch if that is what people want. > Does Microsoft have documentation for how the Windows epoch deals with > Gregorian calendar conversions and leap seconds? There isn't anything that pops out at me from Google. If you can provide me a list of boundary times to check I can construct a test application that uses SYSTEMTIME to FILETIME conversions to test the results of various time arithmetic operations. typedef struct _SYSTEMTIME { WORD wYear; WORD wMonth; WORD wDayOfWeek; WORD wDay; WORD wHour; WORD wMinute; WORD wSecond; WORD wMilliseconds; } SYSTEMTIME, *PSYSTEMTIME; --------------enigF4A4B8C5B5CC41684FB59F42 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iQEcBAEBAgAGBQJONxUiAAoJENxm1CNJffh4mu4H/A7+rbmqi6FER4MuMi1/q+SY lFwytYN63cqi9l0wcFnOohPlGYHF3NoKG8U71oZiTqLYdjG5mfi/BNQAU4Y+7aQ3 117nRk16TBN3UfdJo8dn/mapBOAlP9Cw9RF0Ac8z9f7416qZ/eHASAsyNiceOvwJ FsiQT9P03z2F+5zEb5/LUn6OGPNVHCB1HVv6TfeUM952Ksd/cmNBgozKlf+rBCDa iiunFEF/2sgHLlaT1iQgZ3TqgfulEJCRwnOSEaD6D+lVTZpCw7AT4UELa/JCNTJj gQ++cQnQ8PFGchd0t0IJhaoqFaAQqT+UZNMNbOvMTo9RkowPHlGqLJy5AbRF91M= =B2Sk -----END PGP SIGNATURE----- --------------enigF4A4B8C5B5CC41684FB59F42-- From shadow@gmail.com Mon Aug 1 22:07:45 2011 From: shadow@gmail.com (Derrick Brashear) Date: Mon, 1 Aug 2011 17:07:45 -0400 Subject: [AFS3-std] Re: A call for consensus on draft-deason-afs3-type-time-02 In-Reply-To: References: <20110728135500.76B9ED@grand.central.org> <4E31776B.1040007@odu.edu> <87ei19yma5.fsf@windlord.stanford.edu> <20110729161932.18bc0ced.adeason@sinenomine.net> <87fwlotw4u.fsf@windlord.stanford.edu> <20110801122810.81b1889c.adeason@sinenomine.net> <20110801125344.e9e45873.adeason@sinenomine.net> Message-ID: On Mon, Aug 1, 2011 at 4:16 PM, Tom Keiser wrote: > On Mon, Aug 1, 2011 at 1:53 PM, Andrew Deason wr= ote: >> On Mon, 1 Aug 2011 13:32:46 -0400 >> Derrick Brashear wrote: >> >>> On Mon, Aug 1, 2011 at 1:28 PM, Andrew Deason = wrote: >>> >>> >> b) the granularity >>> > >>> > This one I still have no idea on. I see reasons for both sides. >>> >>> So is there a reason an extended union with the various stamp >>> granularities would be a nonstarter? In particular I'd suggest the >>> draft strongly discourage >>> sending a larger timestamp than actual information supports (e.g. >>> don't use bits to send precision you don't have, rather than >>> trailing-zero-padding a >>> larger than needed number) >> >> Well, the objection to just having 64-bit seconds and 32-bit nanoseconds >> is "space", and a union tag is an extra 32 bits... If we had a "100 NS >> granularity" tag, then we'd have 100-ns granularity in 96 bits, whereas >> now we could have 1-ns granularity in 96 bits. Unless there's some other >> scheme you're thinking of that somehow makes this more efficient? >> > > This is why in Pittsburgh we proposed that overarching structures > (e.g., AFSFetchStatus, and AFSStoreStatus) should be wrapped in > ext-union, while proscribing the use of union/ext-union for individual > members of those structures. =A0As I suggested last Friday, we could > define two different AFSFetchStatus/AFSStoreStatus implied legs for > now: one with 64-bit time, and a second with 96-bit time (perhaps, we > would also want to define a third leg with 32-bit time--given that > we're likely to have implementations of the protocol long before > server backing stores can handle the increased resolution)... and this approach would be fine for this, at least for a long time in the interim. From rra@stanford.edu Mon Aug 1 22:16:18 2011 From: rra@stanford.edu (Russ Allbery) Date: Mon, 01 Aug 2011 14:16:18 -0700 Subject: [AFS3-std] Re: A call for consensus on draft-deason-afs3-type-time-02 In-Reply-To: <4E371520.2050905@secure-endpoints.com> (Jeffrey Altman's message of "Mon, 01 Aug 2011 17:05:36 -0400") References: <20110728135500.76B9ED@grand.central.org> <4E31776B.1040007@odu.edu> <87ei19yma5.fsf@windlord.stanford.edu> <20110729161932.18bc0ced.adeason@sinenomine.net> <87fwlotw4u.fsf@windlord.stanford.edu> <87wrex836y.fsf@windlord.stanford.edu> <4E36E4D7.9010308@secure-endpoints.com> <87fwll81hg.fsf@windlord.stanford.edu> <4E36E9F5.9000502@secure-endpoints.com> <871ux580f5.fsf@windlord.stanford.edu> <4E371520.2050905@secure-endpoints.com> Message-ID: <87livc6del.fsf@windlord.stanford.edu> Jeffrey Altman writes: > If you can provide me a list of boundary times to check I can construct > a test application that uses SYSTEMTIME to FILETIME conversions to test > the results of various time arithmetic operations. > typedef struct _SYSTEMTIME { > WORD wYear; > WORD wMonth; > WORD wDayOfWeek; > WORD wDay; > WORD wHour; > WORD wMinute; > WORD wSecond; > WORD wMilliseconds; > } SYSTEMTIME, *PSYSTEMTIME; Usually the interesting ones for Gregorian conversion of software written in the US are around the date of UK transition from Julian to Gregorian in September of 1752: September 1752 Su Mo Tu We Th Fr Sa 1 2 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 (gcal is one of the few programs I know that attempts to cope with this.) My guess is that Windows is using a backwards-projection of UTC without leap seconds and not attempting to worry about dates that theoretically should be in Julian, so you'll get an offset of 10 or 11 days relative to the actual historical time when converting from a timestamp to calendar time. -- Russ Allbery (rra@stanford.edu) From jaltman@secure-endpoints.com Mon Aug 1 22:20:06 2011 From: jaltman@secure-endpoints.com (Jeffrey Altman) Date: Mon, 01 Aug 2011 17:20:06 -0400 Subject: [AFS3-std] Re: A call for consensus on draft-deason-afs3-type-time-02 In-Reply-To: <87livc6del.fsf@windlord.stanford.edu> References: <20110728135500.76B9ED@grand.central.org> <4E31776B.1040007@odu.edu> <87ei19yma5.fsf@windlord.stanford.edu> <20110729161932.18bc0ced.adeason@sinenomine.net> <87fwlotw4u.fsf@windlord.stanford.edu> <87wrex836y.fsf@windlord.stanford.edu> <4E36E4D7.9010308@secure-endpoints.com> <87fwll81hg.fsf@windlord.stanford.edu> <4E36E9F5.9000502@secure-endpoints.com> <871ux580f5.fsf@windlord.stanford.edu> <4E371520.2050905@secure-endpoints.com> <87livc6del.fsf@windlord.stanford.edu> Message-ID: <4E371886.8010307@secure-endpoints.com> This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig2647EB98B812449AC7E31696 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 8/1/2011 5:16 PM, Russ Allbery wrote: > Jeffrey Altman writes: >=20 >> If you can provide me a list of boundary times to check I can construc= t >> a test application that uses SYSTEMTIME to FILETIME conversions to tes= t >> the results of various time arithmetic operations. >=20 >> typedef struct _SYSTEMTIME { >> WORD wYear; >> WORD wMonth; >> WORD wDayOfWeek; >> WORD wDay; >> WORD wHour; >> WORD wMinute; >> WORD wSecond; >> WORD wMilliseconds; >> } SYSTEMTIME, *PSYSTEMTIME; >=20 > Usually the interesting ones for Gregorian conversion of software writt= en > in the US are around the date of UK transition from Julian to Gregorian= in > September of 1752: >=20 > September 1752 > Su Mo Tu We Th Fr Sa > 1 2 14 15 16 > 17 18 19 20 21 22 23 > 24 25 26 27 28 29 30 >=20 > (gcal is one of the few programs I know that attempts to cope with this= =2E) >=20 > My guess is that Windows is using a backwards-projection of UTC without= > leap seconds and not attempting to worry about dates that theoretically= > should be in Julian, so you'll get an offset of 10 or 11 days relative = to > the actual historical time when converting from a timestamp to calendar= > time. >=20 Provide times for a few known leap seconds and I can test those as well. --------------enig2647EB98B812449AC7E31696 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iQEcBAEBAgAGBQJONxiIAAoJENxm1CNJffh49/AH/1MZZLyAQ9mIiabhFyZnFHuv FFjEX67+JHztWs7JmIZvz6vEFtrPggpRl2CFXC9kf5dT3eNckXMI3kMEaQRz+YUN cUats8XTrifl8BABP1u9n6xK8DWd3v+YBgrMumCn5ckVUzi+4VaQIrFqBqCfsig2 i2KN9IXVDtyHE5i0pcOxo6lmKYlgN1aMWh8gOSPXep/iQ13YvTWXBqrGxiGjzTLt rfz9AaySkkuVKbVGtRw/WIJn+P1J3MpfPnWWpEVHOfgFJp+1Gv0n5ILUYCpxxlV/ 0AOalh7nl+T/bQDR9oAfDL1kxwRCUCuO1mZbD9XLv+mdcbZ7/muv4PLLkhF85qw= =o4oS -----END PGP SIGNATURE----- --------------enig2647EB98B812449AC7E31696-- From rra@stanford.edu Mon Aug 1 22:30:35 2011 From: rra@stanford.edu (Russ Allbery) Date: Mon, 01 Aug 2011 14:30:35 -0700 Subject: [AFS3-std] Re: A call for consensus on draft-deason-afs3-type-time-02 In-Reply-To: <4E371886.8010307@secure-endpoints.com> (Jeffrey Altman's message of "Mon, 01 Aug 2011 17:20:06 -0400") References: <20110728135500.76B9ED@grand.central.org> <4E31776B.1040007@odu.edu> <87ei19yma5.fsf@windlord.stanford.edu> <20110729161932.18bc0ced.adeason@sinenomine.net> <87fwlotw4u.fsf@windlord.stanford.edu> <87wrex836y.fsf@windlord.stanford.edu> <4E36E4D7.9010308@secure-endpoints.com> <87fwll81hg.fsf@windlord.stanford.edu> <4E36E9F5.9000502@secure-endpoints.com> <871ux580f5.fsf@windlord.stanford.edu> <4E371520.2050905@secure-endpoints.com> <87livc6del.fsf@windlord.stanford.edu> <4E371886.8010307@secure-endpoints.com> Message-ID: <87bow86cqs.fsf@windlord.stanford.edu> Jeffrey Altman writes: > Provide times for a few known leap seconds and I can test those as well. Leap seconds are always added as 23:60 on June 30th or December 31st. There's a table at: http://en.wikipedia.org/wiki/Leap_second of all the leap seconds that have been added historically. So: 1972-06-30 23:59:59 1972-06-30 23:59:60 1972-07-01 00:00:00 for example. One of the interesting questions is whether conversion of the first and last calendar times above are, when represented as timestamps, one second apart or two seconds apart. Note that, in POSIX, they're one second apart, because POSIX time contains no leap seconds by definition (which means that it's not really possible to accurately represent those dates). On UNIX systems, using mktime on those dates will generally convert as follows: 1972-06-30 23:59:59 78821999 1972-06-30 23:59:60 78822000 1972-07-01 00:00:00 78822000 There's not really a "right" answer here; we just need to say what the answer is. -- Russ Allbery (rra@stanford.edu) From jhutz@cmu.edu Tue Aug 2 00:17:16 2011 From: jhutz@cmu.edu (Jeffrey Hutzelman) Date: Mon, 01 Aug 2011 19:17:16 -0400 Subject: [AFS3-std] Re: Election Procedure for AFS-3 Working Group Chairs In-Reply-To: <4E3710F3.3000603@anl.gov> References: <4E3710F3.3000603@anl.gov> Message-ID: <1312240636.3168.25.camel@destiny.pc.cs.cmu.edu> On Mon, 2011-08-01 at 15:47 -0500, Douglas E. Engert wrote: > http://tools.ietf.org/id/draft-wilkinson-afs3-standardisation-00.txt > > Says its time for an election, typically with nominations starting > August 1, for 14 days, voting for 14 days, and 7 days to count with > the new chair starting on October 1. > > It is my position that is up for election, as I have the one year > term. Hartmut Reuter is the other co-chair with the 2 year term. > > Please read section 2.2.2 as to who can be nominated, and who can vote. > > (We will need a list of eligible voters, from the mailman-owner > for our list. Once we get that we can start the nomination process, > and keep within the guidelines and have a chair by October 1.) According to section 2.2.2, the list of eligible voters consists of anyone who has posted or was subscribed during the period from June 1 to July 1. It's fairly easy to construct a list of who has posted by consulting the list archives, which are publicly available at https://lists.openafs.org/pipermail/afs3-standardization/ The subscriber list is not public; however, any subscriber can obtain a copy by filling in his username and password near the bottom of the page at https://lists.openafs.org/mailman/listinfo/afs3-standardization and selecting "Visit Subscriber List". Of course, that's as of today. To build a voter list, you also need to know that there have been no new subscribers and no one has unsubscribed since April 25, before the start of the eligibility period. -- Jeff From deengert@anl.gov Tue Aug 2 17:26:34 2011 From: deengert@anl.gov (Douglas E. Engert) Date: Tue, 02 Aug 2011 11:26:34 -0500 Subject: [AFS3-std] Call for nomination for the position of AFS3-standardization co-chair Message-ID: <4E38253A.6000001@anl.gov> http://tools.ietf.org/id/draft-wilkinson-afs3-standardisation-00.txt defines our election procedures to elect a co-chair. It is my position that is up for election, as I have the one year term. Hartmut Reuter is the other co-chair with the 2 year term, due to expire next year. Schedule: Nominations open 8/2 - 8/16 Announcement of nominations 8/17 Voting 8-17 - 8/31 Election results 9/7 Please read section 2.2.2 as to who can be nominated, and who can vote. Send nominations to Hartmut and myself as the vote takers, and we can contact the potential nominees to make sure they are willing to serve. As Jeff points out: > The subscriber list is not public; however, any subscriber can obtain a > copy by filling in his username and password near the bottom of the page > at https://lists.openafs.org/mailman/listinfo/afs3-standardization and > selecting "Visit Subscriber List". Of course, that's as of today. To > build a voter list, you also need to know that there have been no new > subscribers and no one has unsubscribed since April 25, before the start > of the eligibility period. (You can also get your password sent to you with the "Edit Options") -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From deengert@anl.gov Fri Aug 5 20:32:15 2011 From: deengert@anl.gov (Douglas E. Engert) Date: Fri, 05 Aug 2011 14:32:15 -0500 Subject: [AFS3-std] Call for nomination for the position of AFS3-standardization co-chair In-Reply-To: <4E38253A.6000001@anl.gov> References: <4E38253A.6000001@anl.gov> Message-ID: <4E3C453F.5060805@anl.gov> I am not running for re-election and so far we have receive only one other nomination. See the schedule below. On 8/2/2011 11:26 AM, Douglas E. Engert wrote: > http://tools.ietf.org/id/draft-wilkinson-afs3-standardisation-00.txt > > defines our election procedures to elect a co-chair. It is my position > that is up for election, as I have the one year term. Hartmut Reuter > is the other co-chair with the 2 year term, due to expire next year. > > Schedule: > Nominations open 8/2 - 8/16 > Announcement of nominations 8/17 > Voting 8-17 - 8/31 > Election results 9/7 > > Please read section 2.2.2 as to who can be nominated, and who can vote. > > Send nominations to Hartmut and myself as the vote takers, and we can > contact the potential nominees to make sure they are willing to serve. > > As Jeff points out: > > The subscriber list is not public; however, any subscriber can obtain a > > copy by filling in his username and password near the bottom of the page > > at https://lists.openafs.org/mailman/listinfo/afs3-standardization and > > selecting "Visit Subscriber List". Of course, that's as of today. To > > build a voter list, you also need to know that there have been no new > > subscribers and no one has unsubscribed since April 25, before the start > > of the eligibility period. > > (You can also get your password sent to you with the "Edit Options") > -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From adeason@sinenomine.net Mon Aug 8 18:32:58 2011 From: adeason@sinenomine.net (Andrew Deason) Date: Mon, 8 Aug 2011 12:32:58 -0500 Subject: [AFS3-std] Re: A call for consensus on draft-deason-afs3-type-time-02 References: <20110728135500.76B9ED@grand.central.org> <4E31776B.1040007@odu.edu> <87ei19yma5.fsf@windlord.stanford.edu> <20110729161932.18bc0ced.adeason@sinenomine.net> <87fwlotw4u.fsf@windlord.stanford.edu> Message-ID: <20110808123258.59cc0539.adeason@sinenomine.net> On Fri, 29 Jul 2011 18:06:25 -0700 Russ Allbery wrote: > Or, hm, I suppose if you squint at it right, you can decide that > "number of seconds" isn't just elapsed actual time, but includes the > leap seconds that were inserted. Which would also work for our > phrasing. Maybe we could just say that explicitly. Something like: > > the number of seconds and nanoseconds since midnight or 0 hour > January 1, 1970 Coordinated Universal Time (UTC), including any > leap seconds inserted into UTC. It's very possible I am backwards on this, but shouldn't this be "excluding any leap seconds"? That is, in our time representation, there is a difference of 1 "second" (however we define "second") between the times 31 Dec 2005 23:59:59 and 01 Jan 2006 00:00:00, even though there was a leap second at 31 Dec 2005 23:59:60. That is, I thought we'd be following UTC more than TAI. And also, I did find another instance of this being mentioned in IETF RFCs. RFC 4049 states in Section 2 (at the top of the second page): The integer value is the number of seconds, excluding leap seconds, after midnight UTC, January 1, 1970. Would that work for us? -- Andrew Deason adeason@sinenomine.net From rra@stanford.edu Mon Aug 8 18:50:11 2011 From: rra@stanford.edu (Russ Allbery) Date: Mon, 08 Aug 2011 10:50:11 -0700 Subject: [AFS3-std] Re: A call for consensus on draft-deason-afs3-type-time-02 In-Reply-To: <20110808123258.59cc0539.adeason@sinenomine.net> (Andrew Deason's message of "Mon, 8 Aug 2011 12:32:58 -0500") References: <20110728135500.76B9ED@grand.central.org> <4E31776B.1040007@odu.edu> <87ei19yma5.fsf@windlord.stanford.edu> <20110729161932.18bc0ced.adeason@sinenomine.net> <87fwlotw4u.fsf@windlord.stanford.edu> <20110808123258.59cc0539.adeason@sinenomine.net> Message-ID: <8762m7ztbg.fsf@windlord.stanford.edu> Andrew Deason writes: > Russ Allbery wrote: >> Or, hm, I suppose if you squint at it right, you can decide that >> "number of seconds" isn't just elapsed actual time, but includes the >> leap seconds that were inserted. Which would also work for our >> phrasing. Maybe we could just say that explicitly. Something like: >> >> the number of seconds and nanoseconds since midnight or 0 hour >> January 1, 1970 Coordinated Universal Time (UTC), including any >> leap seconds inserted into UTC. > It's very possible I am backwards on this, but shouldn't this be > "excluding any leap seconds"? Oh, yes, you're exactly right. Thank you. > That is, in our time representation, there is a difference of 1 "second" > (however we define "second") between the times 31 Dec 2005 23:59:59 and > 01 Jan 2006 00:00:00, even though there was a leap second at 31 Dec 2005 > 23:59:60. That is, I thought we'd be following UTC more than TAI. Yes, correct. > And also, I did find another instance of this being mentioned in IETF > RFCs. RFC 4049 states in Section 2 (at the top of the second page): > The integer value is the number of seconds, excluding leap seconds, > after midnight UTC, January 1, 1970. > Would that work for us? That sounds great to me. We could take the same approach if we use the other epoch, although I think we should be more wordy about it: The integer value is the number of seconds, excluding leap seconds, after midnight, January 1, 1601 Coordinated Universal Time (UTC), in the Gregorian calendar. NOTE: Neither the Gregorian calendar or the modern UTC time zone were in use in most of the world at that date, but times are represented as if they were, using the obvious backwards projection of the current UTC time zone and Gregorian calendar rules to January 1, 1601. Be aware that any real-world times from that era will likely require Julian to Gregorian calendar conversions to be represented in this format and probably cannot be simply converted using normal time conversions from the modern era. I think that phrasing would resolve my objections to the epoch, along with the additional bits that are in the current draft about how to convert. -- Russ Allbery (rra@stanford.edu) From adeason@sinenomine.net Mon Aug 8 18:54:03 2011 From: adeason@sinenomine.net (Andrew Deason) Date: Mon, 8 Aug 2011 12:54:03 -0500 Subject: [AFS3-std] Re: A call for consensus on draft-deason-afs3-type-time-02 References: <4E2082C6.80609@anl.gov> Message-ID: <20110808125403.f9b913b3.adeason@sinenomine.net> On Fri, 15 Jul 2011 13:11:18 -0500 "Douglas E. Engert" wrote: > http://datatracker.ietf.org/doc/draft-deason-afs3-type-time/ Based on the threads in afs3-stds, and on discussions I've had with others, I propose the following going forward. This is what I'm working on for an -03 draft, and it's what will appear unless I hear objections. The epoch will be changed to the Unix epoch. Absolute time will be signed so we can still represent the windows stuff. The language will also be changed a bit according to Russ's suggestions ("number of seconds since 1970 excluding leap seconds" or whatever it turns out to be, see this sub-thread: ). The granularity in this draft will not be changed. However, additional types will be proposed to be used for higher efficiency and higher granularity. That is, the current types will be AFSAbsTime64 which corresponds to 64-bit 100-ns time, but we will also have types such as AFSAbsTime32 (32-bit 1-s time) and AFSAbsTime96 (64-bit 1-s time plus 32-bit 1-ns). RPCs for which this matters will use some way of accomodating and specifying these other types, but how they do so is outside the scope of this draft (in theory this could be unions, extended unions, separate RPCs etc; in practice right now we expect extended unions). In the interest of getting this i-d done as quickly as we can, the other time types will not be added to this draft, but will be proposed in separate i-ds and if we need to we can argue about them then. So, the only change for draft-deason-afs3-type-time is that the type names will be changed to AFSAbsTime64 etc, and I will include a paragraph discussing the rationale and the future use of other time types for interoperability and efficiency. I feel this will satisfy everyone's concerns, as this approach should allow us to interoperate well with other systems, but the common case should be kept nearly as efficient as the current draft. -- Andrew Deason adeason@sinenomine.net From adeason@sinenomine.net Mon Aug 8 18:58:57 2011 From: adeason@sinenomine.net (Andrew Deason) Date: Mon, 8 Aug 2011 12:58:57 -0500 Subject: [AFS3-std] Re: A call for consensus on draft-deason-afs3-type-time-02 References: <20110728135500.76B9ED@grand.central.org> <4E31776B.1040007@odu.edu> <87ei19yma5.fsf@windlord.stanford.edu> <20110729161932.18bc0ced.adeason@sinenomine.net> <87fwlotw4u.fsf@windlord.stanford.edu> <20110808123258.59cc0539.adeason@sinenomine.net> <8762m7ztbg.fsf@windlord.stanford.edu> Message-ID: <20110808125857.a055922a.adeason@sinenomine.net> On Mon, 08 Aug 2011 10:50:11 -0700 Russ Allbery wrote: > We could take the same approach if we use the other epoch, although I > think we should be more wordy about it: Oh, I thought we'd just use the Unix epoch since it just makes some of this easier. A note on converting to pre-UTC dates seems good, though. Also just by the way, NTPv4 apparently uses an epoch in 1900. They have this to say about it in RFC 5905: In the date and timestamp formats, the prime epoch, or base date of era 0, is 0 h 1 January 1900 UTC, when all bits are zero. It should be noted that strictly speaking, UTC did not exist prior to 1 January 1972, but it is convenient to assume it has existed for all eternity, even if all knowledge of historic leap seconds has been lost. -- Andrew Deason adeason@sinenomine.net From rra@stanford.edu Mon Aug 8 20:50:40 2011 From: rra@stanford.edu (Russ Allbery) Date: Mon, 08 Aug 2011 12:50:40 -0700 Subject: [AFS3-std] Re: A call for consensus on draft-deason-afs3-type-time-02 In-Reply-To: <20110808125857.a055922a.adeason@sinenomine.net> (Andrew Deason's message of "Mon, 8 Aug 2011 12:58:57 -0500") References: <20110728135500.76B9ED@grand.central.org> <4E31776B.1040007@odu.edu> <87ei19yma5.fsf@windlord.stanford.edu> <20110729161932.18bc0ced.adeason@sinenomine.net> <87fwlotw4u.fsf@windlord.stanford.edu> <20110808123258.59cc0539.adeason@sinenomine.net> <8762m7ztbg.fsf@windlord.stanford.edu> <20110808125857.a055922a.adeason@sinenomine.net> Message-ID: <87k4any967.fsf@windlord.stanford.edu> Andrew Deason writes: > Russ Allbery wrote: >> We could take the same approach if we use the other epoch, although I >> think we should be more wordy about it: > Oh, I thought we'd just use the Unix epoch since it just makes some of > this easier. A note on converting to pre-UTC dates seems good, though. Jeffrey has a good point, though: we lose representability of dates that can currently be handled with CIFS. > Also just by the way, NTPv4 apparently uses an epoch in 1900. They have > this to say about it in RFC 5905: > In the date and timestamp formats, the prime epoch, or base date of > era 0, is 0 h 1 January 1900 UTC, when all bits are zero. It should > be noted that strictly speaking, UTC did not exist prior to 1 > January 1972, but it is convenient to assume it has existed for all > eternity, even if all knowledge of historic leap seconds has been > lost. Yeah, that's similar in intention to my note. -- Russ Allbery (rra@stanford.edu) From adeason@sinenomine.net Mon Aug 8 21:42:13 2011 From: adeason@sinenomine.net (Andrew Deason) Date: Mon, 8 Aug 2011 15:42:13 -0500 Subject: [AFS3-std] Re: A call for consensus on draft-deason-afs3-type-time-02 References: <20110728135500.76B9ED@grand.central.org> <4E31776B.1040007@odu.edu> <87ei19yma5.fsf@windlord.stanford.edu> <20110729161932.18bc0ced.adeason@sinenomine.net> <87fwlotw4u.fsf@windlord.stanford.edu> <20110808123258.59cc0539.adeason@sinenomine.net> <8762m7ztbg.fsf@windlord.stanford.edu> <20110808125857.a055922a.adeason@sinenomine.net> <87k4any967.fsf@windlord.stanford.edu> Message-ID: <20110808154213.4ce21908.adeason@sinenomine.net> On Mon, 08 Aug 2011 12:50:40 -0700 Russ Allbery wrote: > Andrew Deason writes: > > Oh, I thought we'd just use the Unix epoch since it just makes some > > of this easier. A note on converting to pre-UTC dates seems good, > > though. > > Jeffrey has a good point, though: we lose representability of dates > that can currently be handled with CIFS. Then we just make the absolute timestamps signed. It just seems better to me to start from an epoch that's a bit more well-defined (or at least, more easily well-defined; we can always define 1 Jan 1600 as X seconds before 1 Jan 1970, but that seems strangely indirect). -- Andrew Deason adeason@sinenomine.net From rra@stanford.edu Mon Aug 8 21:49:42 2011 From: rra@stanford.edu (Russ Allbery) Date: Mon, 08 Aug 2011 13:49:42 -0700 Subject: [AFS3-std] Re: A call for consensus on draft-deason-afs3-type-time-02 In-Reply-To: <20110808154213.4ce21908.adeason@sinenomine.net> (Andrew Deason's message of "Mon, 8 Aug 2011 15:42:13 -0500") References: <20110728135500.76B9ED@grand.central.org> <4E31776B.1040007@odu.edu> <87ei19yma5.fsf@windlord.stanford.edu> <20110729161932.18bc0ced.adeason@sinenomine.net> <87fwlotw4u.fsf@windlord.stanford.edu> <20110808123258.59cc0539.adeason@sinenomine.net> <8762m7ztbg.fsf@windlord.stanford.edu> <20110808125857.a055922a.adeason@sinenomine.net> <87k4any967.fsf@windlord.stanford.edu> <20110808154213.4ce21908.adeason@sinenomine.net> Message-ID: <87sjpbwrvd.fsf@windlord.stanford.edu> Andrew Deason writes: > Russ Allbery wrote: >> Jeffrey has a good point, though: we lose representability of dates >> that can currently be handled with CIFS. > Then we just make the absolute timestamps signed. It just seems better > to me to start from an epoch that's a bit more well-defined (or at > least, more easily well-defined; we can always define 1 Jan 1600 as X > seconds before 1 Jan 1970, but that seems strangely indirect). I guess I'm ambivalent between signed timestamps and the Windows epoch. Both of them are going to be at least somewhat unusual for typical UNIX code. My guess is that it will be easier to explain the Windows epoch than it will be to explain signed arithmetic on times, but I could be wrong. -- Russ Allbery (rra@stanford.edu) From jaltman@secure-endpoints.com Mon Aug 8 22:25:48 2011 From: jaltman@secure-endpoints.com (Jeffrey Altman) Date: Mon, 08 Aug 2011 17:25:48 -0400 Subject: [AFS3-std] Re: A call for consensus on draft-deason-afs3-type-time-02 In-Reply-To: <20110808154213.4ce21908.adeason@sinenomine.net> References: <20110728135500.76B9ED@grand.central.org> <4E31776B.1040007@odu.edu> <87ei19yma5.fsf@windlord.stanford.edu> <20110729161932.18bc0ced.adeason@sinenomine.net> <87fwlotw4u.fsf@windlord.stanford.edu> <20110808123258.59cc0539.adeason@sinenomine.net> <8762m7ztbg.fsf@windlord.stanford.edu> <20110808125857.a055922a.adeason@sinenomine.net> <87k4any967.fsf@windlord.stanford.edu> <20110808154213.4ce21908.adeason@sinenomine.net> Message-ID: <4E40545C.6080600@secure-endpoints.com> This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig4AFFD422C27516B82CF3A430 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 8/8/2011 4:42 PM, Andrew Deason wrote: > On Mon, 08 Aug 2011 12:50:40 -0700 > Russ Allbery wrote: >=20 >> Andrew Deason writes: >>> Oh, I thought we'd just use the Unix epoch since it just makes some >>> of this easier. A note on converting to pre-UTC dates seems good, >>> though. >> >> Jeffrey has a good point, though: we lose representability of dates >> that can currently be handled with CIFS. >=20 > Then we just make the absolute timestamps signed. It just seems better > to me to start from an epoch that's a bit more well-defined (or at > least, more easily well-defined; we can always define 1 Jan 1600 as X > seconds before 1 Jan 1970, but that seems strangely indirect). I don't have a strong feeling about the epoch. I am fine with negative timestamp values. --------------enig4AFFD422C27516B82CF3A430 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iQEcBAEBAgAGBQJOQFRfAAoJENxm1CNJffh41zQH/1a3yikgeEdDGPesg+i901Bu vj/9ivedJ558iUUp4IuR4lC+JB236gh9AH0Mb5lt3FTPkfkX7nM+K9ZH5zDHFhSO O+6TPvMtogJZi94yB7O/1M0cWy+D2NbY+glWBtZCzzOYf1xOyrgSozr+D6xwykS/ pVE8NpJ4zApX/94d1pNWXa+wIRSQO1RTJ2nQR8hLCMGUFaQapwKmpAPKhglKJFFH Jl9gvt9Pb5eCFiqq5VO+ps49Ny8lCYL/49HMeF1jGSJyWs8cDJklKq3BFCn5ansd HzN0ksSlJC6YRlj12EtacdoG0hrym2+BNCMNh2MdPduR24av5D7Aiur0b2rrWb4= =47yu -----END PGP SIGNATURE----- --------------enig4AFFD422C27516B82CF3A430-- From deengert@anl.gov Wed Aug 10 13:48:38 2011 From: deengert@anl.gov (Douglas E. Engert) Date: Wed, 10 Aug 2011 07:48:38 -0500 Subject: [AFS3-std] Call for nomination for the position of AFS3-standardization co-chair In-Reply-To: <4E38253A.6000001@anl.gov> References: <4E38253A.6000001@anl.gov> Message-ID: <4E427E26.9040009@anl.gov> Let me restate this again, we have received only one nomination, so I have also nominated 2 people. We are waiting for these 3 people to respond that they would be willing to run. So please send in nominations to Hartmut and myself. On 8/2/2011 11:26 AM, Douglas E. Engert wrote: > http://tools.ietf.org/id/draft-wilkinson-afs3-standardisation-00.txt > > defines our election procedures to elect a co-chair. It is my position > that is up for election, as I have the one year term. Hartmut Reuter > is the other co-chair with the 2 year term, due to expire next year. > > Schedule: > Nominations open 8/2 - 8/16 > Announcement of nominations 8/17 > Voting 8-17 - 8/31 > Election results 9/7 > > Please read section 2.2.2 as to who can be nominated, and who can vote. > > Send nominations to Hartmut and myself as the vote takers, and we can > contact the potential nominees to make sure they are willing to serve. > > As Jeff points out: > > The subscriber list is not public; however, any subscriber can obtain a > > copy by filling in his username and password near the bottom of the page > > at https://lists.openafs.org/mailman/listinfo/afs3-standardization and > > selecting "Visit Subscriber List". Of course, that's as of today. To > > build a voter list, you also need to know that there have been no new > > subscribers and no one has unsubscribed since April 25, before the start > > of the eligibility period. > > (You can also get your password sent to you with the "Edit Options") > -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 _______________________________________________ AFS3-standardization mailing list AFS3-standardization@openafs.org http://lists.openafs.org/mailman/listinfo/afs3-standardization From jhutz@cmu.edu Wed Aug 10 13:58:17 2011 From: jhutz@cmu.edu (Jeffrey Hutzelman) Date: Wed, 10 Aug 2011 08:58:17 -0400 Subject: [AFS3-std] Call for nomination for the position of AFS3-standardization co-chair In-Reply-To: <4E427E26.9040009@anl.gov> References: <4E38253A.6000001@anl.gov> <4E427E26.9040009@anl.gov> Message-ID: <1312981097.3168.159.camel@destiny.pc.cs.cmu.edu> On Wed, 2011-08-10 at 07:48 -0500, Douglas E. Engert wrote: > Let me restate this again, we have received only one nomination, > so I have also nominated 2 people. We are waiting for these 3 > people to respond that they would be willing to run. Per 2.2.2, nominations are supposed to be sent to this mailing list, and each nomination should be made and seconded by eligible voters. I don't see that any nominations have gone to the list so far. It would be good if those who have already made nominations would copy them to the list; otherwise it will be hard to get a second. :-) -- Jeff From deengert@anl.gov Wed Aug 10 14:08:24 2011 From: deengert@anl.gov (Douglas E. Engert) Date: Wed, 10 Aug 2011 08:08:24 -0500 Subject: [AFS3-std] Call for nomination for the position of AFS3-standardization co-chair In-Reply-To: <1312981097.3168.159.camel@destiny.pc.cs.cmu.edu> References: <4E38253A.6000001@anl.gov> <4E427E26.9040009@anl.gov> <1312981097.3168.159.camel@destiny.pc.cs.cmu.edu> Message-ID: <4E4282C8.8030702@anl.gov> On 8/10/2011 7:58 AM, Jeffrey Hutzelman wrote: > On Wed, 2011-08-10 at 07:48 -0500, Douglas E. Engert wrote: >> Let me restate this again, we have received only one nomination, >> so I have also nominated 2 people. We are waiting for these 3 >> people to respond that they would be willing to run. > > Per 2.2.2, nominations are supposed to be sent to this mailing list, and > each nomination should be made and seconded by eligible voters. I don't > see that any nominations have gone to the list so far. It would be good > if those who have already made nominations would copy them to the list; > otherwise it will be hard to get a second. :-) Good point. So far no one has indicated that they are "Any consenting individual" so I have not put their name out. The other note sent to the vote takers, gave a name, and I am waiting for a reply as to weither that individual is willing. > > -- Jeff > > -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From deengert@anl.gov Wed Aug 10 14:45:50 2011 From: deengert@anl.gov (Douglas E. Engert) Date: Wed, 10 Aug 2011 08:45:50 -0500 Subject: [AFS3-std] Call for nomination for the position of AFS3-standardization co-chair In-Reply-To: <4E38253A.6000001@anl.gov> References: <4E38253A.6000001@anl.gov> Message-ID: <4E428B8E.9040602@anl.gov> I (as a group member, not as co-chair) would like to place in nomination for the co-chair of the AFS3-standardization group, Jeffrey Hutzelman. Jeff's IETF experiences, knowledge of AFS, and organizations skills make him an ideal candidate for the position. On 8/2/2011 11:26 AM, Douglas E. Engert wrote: > http://tools.ietf.org/id/draft-wilkinson-afs3-standardisation-00.txt > > defines our election procedures to elect a co-chair. It is my position > that is up for election, as I have the one year term. Hartmut Reuter > is the other co-chair with the 2 year term, due to expire next year. > > Schedule: > Nominations open 8/2 - 8/16 > Announcement of nominations 8/17 > Voting 8-17 - 8/31 > Election results 9/7 > > Please read section 2.2.2 as to who can be nominated, and who can vote. > > Send nominations to Hartmut and myself as the vote takers, and we can > contact the potential nominees to make sure they are willing to serve. > > As Jeff points out: > > The subscriber list is not public; however, any subscriber can obtain a > > copy by filling in his username and password near the bottom of the page > > at https://lists.openafs.org/mailman/listinfo/afs3-standardization and > > selecting "Visit Subscriber List". Of course, that's as of today. To > > build a voter list, you also need to know that there have been no new > > subscribers and no one has unsubscribed since April 25, before the start > > of the eligibility period. > > (You can also get your password sent to you with the "Edit Options") > -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From matt@linuxbox.com Wed Aug 10 15:10:02 2011 From: matt@linuxbox.com (Matt W. Benjamin) Date: Wed, 10 Aug 2011 10:10:02 -0400 (EDT) Subject: [AFS3-std] Call for nomination for the position of AFS3-standardization co-chair In-Reply-To: <4E428B8E.9040602@anl.gov> Message-ID: <562730635.18.1312985402484.JavaMail.root@thunderbeast.private.linuxbox.com> Second. ----- "Douglas E. Engert" wrote: > I (as a group member, not as co-chair) would like to place in > nomination > for the co-chair of the AFS3-standardization group, Jeffrey > Hutzelman. > > Jeff's IETF experiences, knowledge of AFS, and > organizations skills make him an ideal candidate for the position. > > -- Matt Benjamin The Linux Box 206 South Fifth Ave. Suite 150 Ann Arbor, MI 48104 http://linuxbox.com tel. 734-761-4689 fax. 734-769-8938 cel. 734-216-5309 From jaltman@secure-endpoints.com Wed Aug 10 16:00:04 2011 From: jaltman@secure-endpoints.com (Jeffrey Altman) Date: Wed, 10 Aug 2011 11:00:04 -0400 Subject: [AFS3-std] Call for nomination for the position of AFS3-standardization co-chair In-Reply-To: <562730635.18.1312985402484.JavaMail.root@thunderbeast.private.linuxbox.com> References: <562730635.18.1312985402484.JavaMail.root@thunderbeast.private.linuxbox.com> Message-ID: <4E429CF4.5060705@secure-endpoints.com> This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig4E96346D395F7DE12DCC99A3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 8/10/2011 10:10 AM, Matt W. Benjamin wrote: > Second. >=20 > ----- "Douglas E. Engert" wrote: >=20 >> I (as a group member, not as co-chair) would like to place in >> nomination >> for the co-chair of the AFS3-standardization group, Jeffrey >> Hutzelman. >> >> Jeff's IETF experiences, knowledge of AFS, and >> organizations skills make him an ideal candidate for the position. >> >> I believe that Jeff would make an excellent chair (if he has time) but would prefer that the Chair not also be a registrar. --------------enig4E96346D395F7DE12DCC99A3 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iQEcBAEBAgAGBQJOQpz3AAoJENxm1CNJffh4YcYH/2UAYaa+ASU7rCdoqMODFk1D efEUmqC1fwllQ+RCfTLzBJdLUM/9a0tT4/EPmKtfQ+TqGAAfe56ncmykpwDsSM+w qsNOPxC+5J9YpAi9CCsNx0i6ynuTAd7i/pLrxl2ZbBGIgHXcTx+GqVLneummsdvb I4KLDxYYIZOhz6LTywKZBIfrm5JuO3SUI1W8JQ+1BbTXjyRl6u+N5qW+8p4JGy0q G7ZXnLMmJwYuW8XqaJqG+q0LOuGiKcggYX9Gzs9o4lGp0B+l0Jf2LftM1Vp8epUO aBAVyhW7MF3tZQEys3K0/r6GVnSiQqJuAB01FTzD5M86wdsnuLp7XW/njYcuy+Y= =EpGd -----END PGP SIGNATURE----- --------------enig4E96346D395F7DE12DCC99A3-- From deengert@anl.gov Wed Aug 10 16:22:50 2011 From: deengert@anl.gov (Douglas E. Engert) Date: Wed, 10 Aug 2011 10:22:50 -0500 Subject: [AFS3-std] Call for nomination for the position of AFS3-standardization co-chair In-Reply-To: <4E429CF4.5060705@secure-endpoints.com> References: <562730635.18.1312985402484.JavaMail.root@thunderbeast.private.linuxbox.com> <4E429CF4.5060705@secure-endpoints.com> Message-ID: <4E42A24A.6090206@anl.gov> On 8/10/2011 10:00 AM, Jeffrey Altman wrote: > On 8/10/2011 10:10 AM, Matt W. Benjamin wrote: >> Second. >> >> ----- "Douglas E. Engert" wrote: >> >>> I (as a group member, not as co-chair) would like to place in >>> nomination >>> for the co-chair of the AFS3-standardization group, Jeffrey >>> Hutzelman. >>> >>> Jeff's IETF experiences, knowledge of AFS, and >>> organizations skills make him an ideal candidate for the position. >>> >>> > > I believe that Jeff would make an excellent chair (if he has time) but > would prefer that the Chair not also be a registrar. I understand. Section 2.3.2 says: "it is proposed to extend the role of registrar to include a number of individuals from the community." So the work could be spread around if that is the issue. > > -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From scs@umich.edu Wed Aug 10 16:53:37 2011 From: scs@umich.edu (Steve Simmons) Date: Wed, 10 Aug 2011 11:53:37 -0400 Subject: [AFS3-std] Re: A call for consensus on draft-deason-afs3-type-time-02 In-Reply-To: <87bow86cqs.fsf@windlord.stanford.edu> References: <20110728135500.76B9ED@grand.central.org> <4E31776B.1040007@odu.edu> <87ei19yma5.fsf@windlord.stanford.edu> <20110729161932.18bc0ced.adeason@sinenomine.net> <87fwlotw4u.fsf@windlord.stanford.edu> <87wrex836y.fsf@windlord.stanford.edu> <4E36E4D7.9010308@secure-endpoints.com> <87fwll81hg.fsf@windlord.stanford.edu> <4E36E9F5.9000502@secure-endpoints.com> <871ux580f5.fsf@windlord.stanford.edu> <4E371520.2050905@secure-endpoints.com> <87livc6del.fsf@windlord.stanford.edu> <4E371886.8010307@secure-endpoints.com> <87bow86cqs.fsf@windlord.stanford.edu> Message-ID: <11B3F212-2286-4452-9917-88D390C380BD@umich.edu> On Aug 1, 2011, at 5:30 PM, Russ Allbery wrote: > . . . One of the interesting questions is whether conversion of > the first and last calendar times above are, when represented as > timestamps, one second apart or two seconds apart. >=20 > Note that, in POSIX, they're one second apart, because POSIX time = contains > no leap seconds by definition (which means that it's not really = possible > to accurately represent those dates). >=20 > On UNIX systems, using mktime on those dates will generally convert as > follows: >=20 > 1972-06-30 23:59:59 78821999 > 1972-06-30 23:59:60 78822000 > 1972-07-01 00:00:00 78822000 >=20 > There's not really a "right" answer here; we just need to say what the > answer is. The last paragraph says it, both w/r/t the POSIX issues above and the = various other time issues discussed in this thread. We don't need to be = absolutely right*, nor do we necessarily need to be fully in agreement = with any other vendor or standards system. We just need to say what we = are doing. I proposed we be broken in the same way POSIX is broken, rather than = being any other brand of broken or inventing our own. :-) Steve * IMHO 'absolutely right' would involved knowing what is right, and = presenting to all the other broken implementations their expected broken = data. The former is beyond our scope and abilities, the latter . . . = well, that way lies madness. Let's face it, 99.99% of the time all we're = talking about are filesystem timestamps. If someone wants to touch a = file with the date Sept 10 1752 and not specify anything else about how = to interpret that date, they deserve the wrongness they get. And anybody = who's doing work where leap seconds and calendar type transitions matter = is not doing it using POSIX, Windows, or any other OS-time = representation.** ** No, I have no freaking idea what they're using.= From deengert@anl.gov Wed Aug 10 22:15:26 2011 From: deengert@anl.gov (Douglas E. Engert) Date: Wed, 10 Aug 2011 16:15:26 -0500 Subject: [AFS3-std] AFS3-standardization Co-Chair Nominations time commitments Message-ID: <4E42F4EE.7020807@anl.gov> One of the potential nominees asked: > Can you give me some idea of what time commitment is required? So far it has been only a few hours a week, but depending on how much you want to get involved, and how many drafts are active, it could be more. There are no meeting you have to attend, and the duties of a co-chair are to keep the group inline, and moving. A co-chair could then leave it up to the author of a draft to handle all the issues for a draft or get more involved if this is not happening. (So far that has not been a problem.) The chair does not have to be an expert in the details of a draft, but needs to recognize that others in the group have issues and if there is general consensuses for a draft. After consensuses, we are submitting our drafts as IETF Independent Submissions to the RFC editor. As this process is designed for individuals, not groups, I have left the submission up to the authors. We are breaking ground as a group in submitting a group approved draft in this way. We have our first draft in that state waiting for the three reviewers (they know who they are) to get their reviews in to the RFC Editor. I have had some e-mail discussions with the IETF RFC Editor on this process. on behalf of the group. When the first draft is reviewed, I expect that there will be some additional text that needs to be added to the draft, and to all our drafts. The individual authors of the drafts will have to do this. It is up to the Chair to keep after them. There are two chairs, Hartmut is the co-chair, for one more year, and the new co-chair will have a 2 year term. So it is up to the chairs how the work is split, and how much time you want to put into it. -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From adeason@sinenomine.net Fri Aug 12 17:31:02 2011 From: adeason@sinenomine.net (Andrew Deason) Date: Fri, 12 Aug 2011 11:31:02 -0500 Subject: [AFS3-std] Re: Call for nomination for the position of AFS3-standardization co-chair In-Reply-To: <4E38253A.6000001@anl.gov> References: <4E38253A.6000001@anl.gov> Message-ID: <20110812113102.6efde0c0.adeason@sinenomine.net> I nominate Mike Meffie for co-chair of the AFS3 standardization group. -- Andrew Deason adeason@sinenomine.net From jhutz@cmu.edu Fri Aug 12 22:08:57 2011 From: jhutz@cmu.edu (Jeffrey Hutzelman) Date: Fri, 12 Aug 2011 17:08:57 -0400 Subject: [AFS3-std] Call for nomination for the position of AFS3-standardization co-chair In-Reply-To: <4E429CF4.5060705@secure-endpoints.com> References: <562730635.18.1312985402484.JavaMail.root@thunderbeast.private.linuxbox.com> <4E429CF4.5060705@secure-endpoints.com> Message-ID: <1313183337.3168.275.camel@destiny.pc.cs.cmu.edu> On Wed, 2011-08-10 at 11:00 -0400, Jeffrey Altman wrote: > On 8/10/2011 10:10 AM, Matt W. Benjamin wrote: > > Second. > > > > ----- "Douglas E. Engert" wrote: > > > >> I (as a group member, not as co-chair) would like to place in > >> nomination > >> for the co-chair of the AFS3-standardization group, Jeffrey > >> Hutzelman. > >> > >> Jeff's IETF experiences, knowledge of AFS, and > >> organizations skills make him an ideal candidate for the position. Accept. > I believe that Jeff would make an excellent chair (if he has time) but > would prefer that the Chair not also be a registrar. I'd very much like to take a -- I was going to say "less active", but I really mean more like "less blocking" -- role in the registrar process. We actually have other registrars; perhaps if we can get them truly spun up to the point where they are handling day-to-day requests, such things can actually be handled day-to-day. That said, I don't think there's a strong conflict here; neither chairs nor registrars are intended as a check on the power of the other. -- Jeff From matt@linuxbox.com Sat Aug 13 01:03:09 2011 From: matt@linuxbox.com (Matt W. Benjamin) Date: Fri, 12 Aug 2011 20:03:09 -0400 (EDT) Subject: [AFS3-std] Re: Call for nomination for the position of AFS3-standardization co-chair In-Reply-To: <20110812113102.6efde0c0.adeason@sinenomine.net> Message-ID: <1764277117.94.1313193789600.JavaMail.root@thunderbeast.private.linuxbox.com> Hi, I will second this, I assume it means Mike is a volunteer. Matt ----- "Andrew Deason" wrote: > I nominate Mike Meffie for co-chair of the AFS3 standardization > group. > > -- > Andrew Deason > adeason@sinenomine.net > _______________________________________________ > AFS3-standardization mailing list > AFS3-standardization@openafs.org > http://lists.openafs.org/mailman/listinfo/afs3-standardization -- Matt Benjamin The Linux Box 206 South Fifth Ave. Suite 150 Ann Arbor, MI 48104 http://linuxbox.com tel. 734-761-4689 fax. 734-769-8938 cel. 734-216-5309 From deengert@anl.gov Tue Aug 16 15:09:01 2011 From: deengert@anl.gov (Douglas E. Engert) Date: Tue, 16 Aug 2011 09:09:01 -0500 Subject: [AFS3-std] Fwd: Re: [rfc-ise] AFS3 Standardization and Independent Submissions Message-ID: <4E4A79FD.2000808@anl.gov> Our first draft is moving through the IETF Independent Submission Process= , and is now waiting for the author. As far as I know, the two other reviewers have not sent in their reviews. and it would be good have have all the reviews in before submitting a new= draft. -------- Original Message -------- Subject: Re: [rfc-ise] AFS3 Standardization and Independent Submissions Date: Sat, 13 Aug 2011 17:15:07 -0700 From: Nevil Brownlee Organization: Independent Stream To: Derrick Brashear CC: ISE , Hartmut Reuter , "D= ouglas E. Engert" Hi Derrick: Henry Hotz has sent me the appended review of your draft, so I've changed its state to ISR-AUTH. Would you please consider his comments, and publi= sh a new revision that addresses them. I'm still waiting for reviews from Simon Wilkinson and Jeff Altman, I'll prod them now! Cheers, Nevil On 08/01/2011 06:21 PM, Henry B. Hotz wrote: > I've looked at and it is generally fine per-se as to content. > > What I see as significant problems are historical artifacts of the stan= dardization process. This document updates a protocol that does not have= a pre-existing standard description. Consequently, there are a number o= f things which are referenced, but not defined. > > The biggie is the Rx protocol itself. The standard reference for that = is Ed Zayas' "AFS-3 Programmer=92s Reference: Specification for the Rx Re= mote Procedure Call Facility", Version 1.2 of 28 August 1991. I don't kn= ow if that should be a normative or informative reference. I'm inclined = to say informative since it isn't a standards document and wasn't even re= ally binding on Transarc when they put it out. > > That document appears to define everything which I had marked as needin= g definition when I read the draft. > > The following comments are just nits: > > An informative reference to "AFS-3 Programmer=92s Reference: Architectu= ral Overview" might also be useful, but not necessary. (It's referenced = by the Rx doc anyway.) > > Section 6 makes no mention of how an entity is authenticated. Not sure= it needs to, but I felt funny about it. > > The sentence "It is expected. . ." near the top of page 6 seems unclear= to me. More generally the language concerning how names are to be compa= red stays strictly to what the GSSAPI standards say. Speaking from exper= ience people violate the "MUST NOT" because they need to deal with case-f= olding caused by Microsoft Active Directory. I wish I had some standards= -confoming procedure which also worked with AD without deployment convent= ions or other presumptions, but I don't. Absent such a thing I can't sug= gest (or even ask for) changes, but I could wish for some language that b= etter reflected practical necessity. > > The PrCapabilities line near the top of page 7 should be indented one m= ore level. > > > On Jun 1, 2011, at 7:00 PM, Nevil Brownlee wrote: > >> >> Hi Henry: >> >> It's been about three weeks since you volunteered to review >> the draft: draft-brashear-afs3-pts-extended-names >> >> Can you estimate when you'll be able to send me the review, >> please? >> >> Cheers, Nevil >> >> >> On 9/05/11 12:26 PM, Jeffrey Altman wrote: >>> Nevil: >>> >>> Both Simon and I will do so. >>> >>> Thanks. >>> >>> Jeffrey Altman >>> >>> >>> On 5/8/2011 6:45 PM, Nevil Brownlee wrote: >>>> >>>> Hi Douglas: >>>> >>>> Yes, you've defined 'independent reviewer' correctly. >>>> >>>> Two reviews would be enough, that would be Henry (not involved >>>> in AFS3 efforts) and one other - Simon and Jeff, could you please >>>> decide which of you will do it? (Of course, if you'd both like to, >>>> that would be fine too). >>>> >>>> Here's the note I usually send to prospective reviewers: >>>> >>>> "would you be prepared to do a more detailed review, with two >>>> parts: >>>> a) Comments for the Authors >>>> Reasons for rejection or suggestions for improvements. >>>> These will be returned to authors (or you may wish to have >>>> email discussions directly with authors). Could they also >>>> be published on the Independent Submissions web site, >>>> either as public reviews or as anonymous reviews? >>>> b) Comments for the Independent Submissions Editor >>>> These are advice to the ISE, and will not be published." >>>> >>>> Cheers, Nevil >> >> -- >> Nevil Brownlee (ISE), rfc-ise@rfc-editor.org > > ------------------------------------------------------ > The opinions expressed in this message are mine, > not those of Caltech, JPL, NASA, or the US Government. > Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu > > > --=20 Nevil Brownlee (ISE), rfc-ise@rfc-editor.org From mmeffie@sinenomine.net Tue Aug 16 17:40:41 2011 From: mmeffie@sinenomine.net (Michael Meffie) Date: Tue, 16 Aug 2011 12:40:41 -0400 Subject: [AFS3-std] Re: Call for nomination for the position of AFS3-standardization co-chair In-Reply-To: <1764277117.94.1313193789600.JavaMail.root@thunderbeast.private.linuxbox.com> References: <1764277117.94.1313193789600.JavaMail.root@thunderbeast.private.linuxbox.com> Message-ID: <4E4A9D89.50600@sinenomine.net> Matt W. Benjamin wrote: > Hi, > > I will second this, I assume it means Mike is a volunteer. Yes, thank you. I do accept the nomination. Mike -- From deengert@anl.gov Wed Aug 17 19:55:01 2011 From: deengert@anl.gov (Douglas E. Engert) Date: Wed, 17 Aug 2011 13:55:01 -0500 Subject: Fwd: [AFS3-std] Call for nomination for the position of AFS3-standardization co-chair Message-ID: <4E4C0E85.90908@anl.gov> Today is the day to announce the nominations. But I am having problems getting in touch with our co-chair, Hartmut. The co-chairs have to agree on the nominations, and count the votes. I have not heard from him since March. I have a note into 3 contacts and the secretaries at rzg.mpg.de to see if they know anything. (They may not see the note till tomorrow.) Has anyone heard anything? (It could just be August is vacation time for many of us, and in the future we should consider moving back the elections till a month or two.) -------- Original Message -------- Subject: [AFS3-std] Call for nomination for the position of AFS3-standardization co-chair Date: Tue, 02 Aug 2011 11:26:34 -0500 From: Douglas E. Engert To: afs3-standardization@openafs.org CC: Hartmut Reuter , "Douglas E. Engert" http://tools.ietf.org/id/draft-wilkinson-afs3-standardisation-00.txt defines our election procedures to elect a co-chair. It is my position that is up for election, as I have the one year term. Hartmut Reuter is the other co-chair with the 2 year term, due to expire next year. Schedule: Nominations open 8/2 - 8/16 Announcement of nominations 8/17 Voting 8-17 - 8/31 Election results 9/7 Please read section 2.2.2 as to who can be nominated, and who can vote. Send nominations to Hartmut and myself as the vote takers, and we can contact the potential nominees to make sure they are willing to serve. As Jeff points out: > The subscriber list is not public; however, any subscriber can obtain a > copy by filling in his username and password near the bottom of the page > at https://lists.openafs.org/mailman/listinfo/afs3-standardization and > selecting "Visit Subscriber List". Of course, that's as of today. To > build a voter list, you also need to know that there have been no new > subscribers and no one has unsubscribed since April 25, before the start > of the eligibility period. (You can also get your password sent to you with the "Edit Options") -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 _______________________________________________ AFS3-standardization mailing list AFS3-standardization@openafs.org http://lists.openafs.org/mailman/listinfo/afs3-standardization From jaltman@secure-endpoints.com Thu Aug 18 02:46:45 2011 From: jaltman@secure-endpoints.com (Jeffrey Altman) Date: Wed, 17 Aug 2011 21:46:45 -0400 Subject: [AFS3-std] Re: A call for consensus on draft-deason-afs3-type-time-02 In-Reply-To: <87k4any967.fsf@windlord.stanford.edu> References: <20110728135500.76B9ED@grand.central.org> <4E31776B.1040007@odu.edu> <87ei19yma5.fsf@windlord.stanford.edu> <20110729161932.18bc0ced.adeason@sinenomine.net> <87fwlotw4u.fsf@windlord.stanford.edu> <20110808123258.59cc0539.adeason@sinenomine.net> <8762m7ztbg.fsf@windlord.stanford.edu> <20110808125857.a055922a.adeason@sinenomine.net> <87k4any967.fsf@windlord.stanford.edu> Message-ID: <4E4C6F05.2070701@secure-endpoints.com> This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig960E6E28E0B52C10FA2FA539 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I came across this today which might be of interest: http://data.iers.org/products/16/14844/orig/bulletinc-042.txt Quoting: "IMPORTANT: After years of discussions, a proposal to fundamentally redefine UTC will come to a conclusive vote in January 2012 at the ITU-R in Geneva. "This proposal would halt the intercalary adjustments known as leap seconds that maintain UTC as a form of Universal Time." If the proposal is approved it the definition would change in five years from the vote. Our input will be accepted on the subject until the end of August. There are some interesting papers linked from the questionnaire. http://hpiers.obspm.fr/eop-pc/index.php?index=3Dquestionnaire --------------enig960E6E28E0B52C10FA2FA539 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iQEcBAEBAgAGBQJOTG8IAAoJENxm1CNJffh4YwoH+gLXPdKaRz766xaAh+8gt6J8 sYjHtmMlBr5PWOaPMBi5LUS/QAXTyhZS/EfyxMang48B/ByM44h07nhtXoe+qW9f xk9s0+s3UnPbjpw3+USi9LoeBgAW2x+LVMpL76be9DBM+iTQ2VQT0KrY9cu7Jy+v mGkLWImwfVkGUQczUdvzKNA1oyAm1VdJuYhOFx7meLK3HBmmJL4wSDizb6HiU7Ze s5tp1NLMSctvTJItRSXb9OebXQEEzlSqyVjG1VXOk1GSaGX7sExPZT3fDc//NcV4 GeeiqaUL4eonGcPoKTYn+bBtaXRMZlJKYrUDTolPZ0b4MophVkmr5uA1bmm+GRU= =txEM -----END PGP SIGNATURE----- --------------enig960E6E28E0B52C10FA2FA539-- From reuter@rzg.mpg.de Thu Aug 18 13:26:53 2011 From: reuter@rzg.mpg.de (Hartmut Reuter) Date: Thu, 18 Aug 2011 14:26:53 +0200 Subject: Fwd: [AFS3-std] Call for nomination for the position of AFS3-standardization co-chair In-Reply-To: <4E4C0E85.90908@anl.gov> References: <4E4C0E85.90908@anl.gov> Message-ID: <4E4D050D.2050201@rzg.mpg.de> Douglas E. Engert wrote: > Today is the day to announce the nominations. But I am having > problems getting in touch with our co-chair, Hartmut. The > co-chairs have to agree on the nominations, and count the votes. > > I have not heard from him since March. I have a note into > 3 contacts and the secretaries at rzg.mpg.de to see if > they know anything. (They may not see the note till tomorrow.) > > Has anyone heard anything? > > (It could just be August is vacation time for many of us, and > in the future we should consider moving back the elections > till a month or two.) > Doug, sorry for the delay, I was in holidays without access to my mail, but now I am back. I have now followed the last weeks of the mailing list and it seems to me that there are only three nominations: Kim Kimball Jeffrey Hutzelman Mike Meffie where Kim still hasn't replied to the question if he would accept his nomination. So now we either could follow strictly Simon Wilkinson's proposal and start the voting with two candidates or we could do it less strictly and wait for an answer of Kim before starting the voting. What do you prefer, Doug? I am open for both ways. Hartmut > > -------- Original Message -------- > Subject: [AFS3-std] Call for nomination for the position of > AFS3-standardization co-chair > Date: Tue, 02 Aug 2011 11:26:34 -0500 > From: Douglas E. Engert > To: afs3-standardization@openafs.org > CC: Hartmut Reuter , "Douglas E. Engert" > > > http://tools.ietf.org/id/draft-wilkinson-afs3-standardisation-00.txt > > defines our election procedures to elect a co-chair. It is my position > that is up for election, as I have the one year term. Hartmut Reuter > is the other co-chair with the 2 year term, due to expire next year. > > Schedule: > Nominations open 8/2 - 8/16 > Announcement of nominations 8/17 > Voting 8-17 - 8/31 > Election results 9/7 > > Please read section 2.2.2 as to who can be nominated, and who can vote. > > Send nominations to Hartmut and myself as the vote takers, and we can > contact the potential nominees to make sure they are willing to serve. > > As Jeff points out: >> The subscriber list is not public; however, any subscriber can obtain a >> copy by filling in his username and password near the bottom of the page >> at https://lists.openafs.org/mailman/listinfo/afs3-standardization and >> selecting "Visit Subscriber List". Of course, that's as of today. To >> build a voter list, you also need to know that there have been no new >> subscribers and no one has unsubscribed since April 25, before the start >> of the eligibility period. > > (You can also get your password sent to you with the "Edit Options") > -- ----------------------------------------------------------------- Hartmut Reuter e-mail reuter@rzg.mpg.de phone +49-89-3299-1328 fax +49-89-3299-1301 RZG (Rechenzentrum Garching) web http://www.rzg.mpg.de/~hwr Computing Center of the Max-Planck-Gesellschaft (MPG) and the Institut fuer Plasmaphysik (IPP) ----------------------------------------------------------------- From deengert@anl.gov Thu Aug 18 15:18:24 2011 From: deengert@anl.gov (Douglas E. Engert) Date: Thu, 18 Aug 2011 09:18:24 -0500 Subject: [AFS3-std] Voting for the position of AFS3-standardization co-chair Message-ID: <4E4D1F30.10003@anl.gov> http://tools.ietf.org/id/draft-wilkinson-afs3-standardisation-00.txt defines our election procedures to elect a co-chair for a 2 year term starting October 1. In the option of the co-chairs we have two candidates: Jeffrey Hutzelman Mike Meffie Jeff was nominated by Doug Engert and seconded by Matt W. Benjamin. Mike was nominated by Andrew Deason and seconded by Matt Benjamin. I am revising the schedule so voting starts today, and and on September 1. Schedule: Nominations open 8/2 - 8/16 Announcement of nominations 8/18 * revised Voting 8-18 - 9/1 * revised Election results 9/7 Please read section 2.2.2 as to who can vote. Send votes to Hartmut and myself as the vote takers, *NOT* to the list. Please use the subject of this email for voting, you can reply to it, but *NOT* to the full list. -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 _______________________________________________ AFS3-standardization mailing list AFS3-standardization@openafs.org http://lists.openafs.org/mailman/listinfo/afs3-standardization From simon@sxw.org.uk Thu Aug 18 15:30:02 2011 From: simon@sxw.org.uk (Simon Wilkinson) Date: Thu, 18 Aug 2011 15:30:02 +0100 Subject: [AFS3-std] Voting for the position of AFS3-standardization co-chair In-Reply-To: <4E4D1F30.10003@anl.gov> References: <4E4D1F30.10003@anl.gov> Message-ID: <9CDA9B32-7881-4404-B5B7-CDE86CCF82F8@sxw.org.uk> As an elector, it would help me in casting my vote if the candidates = would be prepared to say something on the list about their vision for = the standardisation process, what time they are prepared to devote to = the job, and how they think we can best move things forwards. Thanks, Simon. From dboyes@sinenomine.net Thu Aug 18 18:20:24 2011 From: dboyes@sinenomine.net (David Boyes) Date: Thu, 18 Aug 2011 12:20:24 -0500 Subject: [AFS3-std] Voting for the position of AFS3-standardization co-chair In-Reply-To: <9CDA9B32-7881-4404-B5B7-CDE86CCF82F8@sxw.org.uk> References: <4E4D1F30.10003@anl.gov> <9CDA9B32-7881-4404-B5B7-CDE86CCF82F8@sxw.org.uk> Message-ID: > As an elector, it would help me in casting my vote if the candidates woul= d be > prepared to say something on the list about their vision for the > standardisation process, what time they are prepared to devote to the job= , > and how they think we can best move things forwards. While an excellent idea, it's not in the process right now. Since we have a= lready started the voting, shouldn't we postpone introducing this until nex= t time (and put this in the charter doc)? -- db From jaltman@secure-endpoints.com Thu Aug 18 18:28:01 2011 From: jaltman@secure-endpoints.com (Jeffrey Altman) Date: Thu, 18 Aug 2011 13:28:01 -0400 Subject: [AFS3-std] Voting for the position of AFS3-standardization co-chair In-Reply-To: References: <4E4D1F30.10003@anl.gov> <9CDA9B32-7881-4404-B5B7-CDE86CCF82F8@sxw.org.uk> Message-ID: <4E4D4BA1.8000809@secure-endpoints.com> This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig8FEAB52BF40AA5AACDC0015E Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 8/18/2011 1:20 PM, David Boyes wrote: >> As an elector, it would help me in casting my vote if the candidates w= ould be >> prepared to say something on the list about their vision for the >> standardisation process, what time they are prepared to devote to the = job, >> and how they think we can best move things forwards. >=20 > While an excellent idea, it's not in the process right now. Since we ha= ve already started the voting, shouldn't we postpone introducing this unt= il next time (and put this in the charter doc)? >=20 > -- db I see no reason why people who are running for an office should feel it within their own powers to communicate with those they are intending to serve. A failure to respond to a request from the community is an indication to me that I shouldn't vote for the unresponsive nominee. It has nothing to do with what is or is not required by the process. Jeffrey Altman --------------enig8FEAB52BF40AA5AACDC0015E Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iQEcBAEBAgAGBQJOTUukAAoJENxm1CNJffh45ngH/3X9SN15SrE6MsBoO2ogdT6x OFHIdXFtOIAC2rHsea1BYBbOfr6e7j//sTvjoTwoQXJDTOa6od2qHy3lh8MI2n/P uaUf/WtsgP9Ad5Hx73oNwSzIUG6IL68j3G/9x1tRUbWgktBUGNo0DKJhvMDB7ZGr F0aQqAyNV8v9gEN8S4i3xjBl1Khk0sJ5ECBZxryUXEsXe/MreVHhntKV7kAe19BW fnjOh0noa1jA1VJYXTT29YrgPBc2lfjM5dNXHmaVefWul3Xi7XY3HSaJvDEQQ1WK FWYIjmlfd1qXjybae1duFODOjQb2Cnr8jvsHBgRhB0xjTXiIrNu2xYYC2swd/yw= =3+Iy -----END PGP SIGNATURE----- --------------enig8FEAB52BF40AA5AACDC0015E-- From dboyes@sinenomine.net Thu Aug 18 18:38:48 2011 From: dboyes@sinenomine.net (David Boyes) Date: Thu, 18 Aug 2011 12:38:48 -0500 Subject: [AFS3-std] Voting for the position of AFS3-standardization co-chair In-Reply-To: <4E4D4BA1.8000809@secure-endpoints.com> References: <4E4D1F30.10003@anl.gov> <9CDA9B32-7881-4404-B5B7-CDE86CCF82F8@sxw.org.uk> <4E4D4BA1.8000809@secure-endpoints.com> Message-ID: PiBBIGZhaWx1cmUgdG8gcmVzcG9uZCB0byBhIHJlcXVlc3QgZnJvbSB0aGUgY29tbXVuaXR5IGlz IGFuIGluZGljYXRpb24gdG8gbWUNCj4gdGhhdCBJIHNob3VsZG4ndCB2b3RlIGZvciB0aGUgdW5y ZXNwb25zaXZlIG5vbWluZWUuICBJdCBoYXMgbm90aGluZyB0byBkbyB3aXRoDQo+IHdoYXQgaXMg b3IgaXMgbm90IHJlcXVpcmVkIGJ5IHRoZSBwcm9jZXNzLg0KDQpJIGRpc2FncmVlLiBXZSdyZSBj aGFuZ2luZyB0aGUgcnVsZXMgbWlkLXN0cmVhbS4gDQoNClJpZ2h0IG5vdywgdGhlcmUgaXMgbm8g cmVxdWlyZW1lbnQgZm9yIGFueW9uZSB0byBwcm92aWRlIGEgc3RhdGVtZW50LiBJZiBzb21lb25l IGRvZXMsIHRoZW4gZ29vZCBmb3IgdGhlbSwgYnV0IHdlIHNob3VsZG4ndCBwZW5hbGl6ZSBwZW9w bGUgZm9yIG5vdCBtYWtpbmcgb25lIGlmIGl0IGlzbid0IHJlcXVpcmVkIGJ5IHRoZSBwcm9jZXNz LiBJdCdzIG5vdCBhIGZhaXIgZXZhbHVhdGlvbiBpZiBldmVyeW9uZSBkb2Vzbid0IGhhdmUgdG8g cGxheSBieSB0aGUgc2FtZSBydWxlcy4gDQpFaXRoZXIgbWFrZSBpdCByZXF1aXJlZCBmb3IgZXZl cnlvbmUsIG9yIGRvbid0IGRvIGl0IChmb3IgdGhpcyB0aW1lKS4gDQoNCi0tIGRiDQoNCg== From adeason@sinenomine.net Thu Aug 18 18:49:03 2011 From: adeason@sinenomine.net (Andrew Deason) Date: Thu, 18 Aug 2011 13:49:03 -0400 Subject: [AFS3-std] Re: Voting for the position of AFS3-standardization co-chair References: <4E4D1F30.10003@anl.gov> <9CDA9B32-7881-4404-B5B7-CDE86CCF82F8@sxw.org.uk> <4E4D4BA1.8000809@secure-endpoints.com> Message-ID: <20110818134903.a314437f.adeason@sinenomine.net> On Thu, 18 Aug 2011 12:38:48 -0500 David Boyes wrote: > > A failure to respond to a request from the community is an > > indication to me that I shouldn't vote for the unresponsive nominee. > > It has nothing to do with what is or is not required by the process. > > I disagree. We're changing the rules mid-stream. > > Right now, there is no requirement for anyone to provide a statement. > If someone does, then good for them, but we shouldn't penalize people > for not making one if it isn't required by the process. The only "penalty" is that Jeff won't vote for them; nowhere do I see that Jeff is suggesting that such candidates would be disqualified or anything like that. Jeff is just expressing a desire as a voter, as far as I can read. It seems good that voters express such opinions, so candidates know what the voters are specifically looking for, if anything. I don't envision myself caring about position statements, but if Jeff does, then... good for him. -- Andrew Deason adeason@sinenomine.net From dboyes@sinenomine.net Thu Aug 18 18:53:43 2011 From: dboyes@sinenomine.net (David Boyes) Date: Thu, 18 Aug 2011 12:53:43 -0500 Subject: [AFS3-std] Re: Voting for the position of AFS3-standardization co-chair In-Reply-To: <20110818134903.a314437f.adeason@sinenomine.net> References: <4E4D1F30.10003@anl.gov> <9CDA9B32-7881-4404-B5B7-CDE86CCF82F8@sxw.org.uk> <4E4D4BA1.8000809@secure-endpoints.com> <20110818134903.a314437f.adeason@sinenomine.net> Message-ID: > The only "penalty" is that Jeff won't vote for them; nowhere do I see tha= t > Jeff is suggesting that such candidates would be disqualified or anything= like > that. Jeff is just expressing a desire as a voter, as far as I can read. Which prima facie gives the people who do supply a statement an advantage i= n that at least one voter will not vote for a candidate that does not suppl= y a statement.=20 > It seems > good that voters express such opinions, so candidates know what the voter= s > are specifically looking for, if anything. Agreed. But then all candidates should supply them.=20 =20 > I don't envision myself caring about position statements, but if Jeff doe= s, > then... good for him. I would like them too. But I want them from all candidates so that I'm comp= aring apples to apples, and that every candidate has an equal probability o= f receiving votes from all the electors.=20 From rra@stanford.edu Thu Aug 18 18:57:07 2011 From: rra@stanford.edu (Russ Allbery) Date: Thu, 18 Aug 2011 10:57:07 -0700 Subject: [AFS3-std] Re: Voting for the position of AFS3-standardization co-chair In-Reply-To: (David Boyes's message of "Thu, 18 Aug 2011 12:53:43 -0500") References: <4E4D1F30.10003@anl.gov> <9CDA9B32-7881-4404-B5B7-CDE86CCF82F8@sxw.org.uk> <4E4D4BA1.8000809@secure-endpoints.com> <20110818134903.a314437f.adeason@sinenomine.net> Message-ID: <87aab6bo24.fsf@windlord.stanford.edu> David Boyes writes: > I would like them too. But I want them from all candidates so that I'm > comparing apples to apples, and that every candidate has an equal > probability of receiving votes from all the electors. You are free to reflect that desire in the way that you vote, in the same way that others are free to reflect their desires for statements in the way that they vote. The rules, so far as I know, don't put any restrictions on what factors influence the votes of the people who are eligible to vote. I suspect we've already exerted more effort arguing about this than it really warranted. -- Russ Allbery (rra@stanford.edu) From adeason@sinenomine.net Thu Aug 18 19:02:23 2011 From: adeason@sinenomine.net (Andrew Deason) Date: Thu, 18 Aug 2011 14:02:23 -0400 Subject: [AFS3-std] Re: Voting for the position of AFS3-standardization co-chair References: <4E4D1F30.10003@anl.gov> <9CDA9B32-7881-4404-B5B7-CDE86CCF82F8@sxw.org.uk> <4E4D4BA1.8000809@secure-endpoints.com> <20110818134903.a314437f.adeason@sinenomine.net> Message-ID: <20110818140223.c5382fd3.adeason@sinenomine.net> On Thu, 18 Aug 2011 12:53:43 -0500 David Boyes wrote: > > I don't envision myself caring about position statements, but if > > Jeff does, then... good for him. > > I would like them too. But I want them from all candidates so that I'm > comparing apples to apples, and that every candidate has an equal > probability of receiving votes from all the electors. I'm not sure what you are suggesting? I think the only request was that everyone does send such a statement. If they don't send one... nothing happens. I'm not sure if you are suggesting that such statements are _required_ (those that don't send one are disqualified), or that nominees _cannot_ send such statements. Both of those sound like rule changes to me moreso than the original requests, but perhaps I am drastically misreading you. If this is just your expression of a voter opinion, then... okay. -- Andrew Deason adeason@sinenomine.net From deengert@anl.gov Thu Aug 18 19:12:13 2011 From: deengert@anl.gov (Douglas E. Engert) Date: Thu, 18 Aug 2011 13:12:13 -0500 Subject: [AFS3-std] Re: Voting for the position of AFS3-standardization co-chair In-Reply-To: <87aab6bo24.fsf@windlord.stanford.edu> References: <4E4D1F30.10003@anl.gov> <9CDA9B32-7881-4404-B5B7-CDE86CCF82F8@sxw.org.uk> <4E4D4BA1.8000809@secure-endpoints.com> <20110818134903.a314437f.adeason@sinenomine.net> <87aab6bo24.fsf@windlord.stanford.edu> Message-ID: <4E4D55FD.8050102@anl.gov> As a co-chair, I see no problem with candidates making statements. On 8/18/2011 12:57 PM, Russ Allbery wrote: > David Boyes writes: > >> I would like them too. But I want them from all candidates so that I'm >> comparing apples to apples, and that every candidate has an equal >> probability of receiving votes from all the electors. > > You are free to reflect that desire in the way that you vote, in the same > way that others are free to reflect their desires for statements in the > way that they vote. The rules, so far as I know, don't put any > restrictions on what factors influence the votes of the people who are > eligible to vote. > > I suspect we've already exerted more effort arguing about this than it > really warranted. > -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From dboyes@sinenomine.net Thu Aug 18 19:15:35 2011 From: dboyes@sinenomine.net (David Boyes) Date: Thu, 18 Aug 2011 13:15:35 -0500 Subject: [AFS3-std] Re: Voting for the position of AFS3-standardization co-chair In-Reply-To: <20110818140223.c5382fd3.adeason@sinenomine.net> References: <4E4D1F30.10003@anl.gov> <9CDA9B32-7881-4404-B5B7-CDE86CCF82F8@sxw.org.uk> <4E4D4BA1.8000809@secure-endpoints.com> <20110818134903.a314437f.adeason@sinenomine.net> <20110818140223.c5382fd3.adeason@sinenomine.net> Message-ID: > I'm not sure what you are suggesting? I am suggesting that in the future, the process be changed to require a sta= tement like the one Simon requested from all candidates. I am also suggesti= ng that while it would be nice to have that for this election voluntarily, = not having it should not be a valid basis for rejecting a candidate for the= current election, since the request occurred after the official start of t= he voting period.=20 I don't have any problem with someone providing a statement. I do have a pr= oblem with people stating that they will reject out of hand a candidate tha= t does not provide one if the request was not present at the start of votin= g.=20 > I'm not sure if you are suggesting that such statements are _required_ > (those that don't send one are disqualified), or that nominees _cannot_ s= end > such statements. Both of those sound like rule changes to me moreso than > the original requests, but perhaps I am drastically misreading you. See above. I would like to see evidence that a candidate has thought about = the long-term process and what they intend to do as chair.=20 From mmeffie@sinenomine.net Thu Aug 18 19:36:59 2011 From: mmeffie@sinenomine.net (Michael Meffie) Date: Thu, 18 Aug 2011 14:36:59 -0400 Subject: [AFS3-std] Voting for the position of AFS3-standardization co-chair In-Reply-To: <9CDA9B32-7881-4404-B5B7-CDE86CCF82F8@sxw.org.uk> References: <4E4D1F30.10003@anl.gov> <9CDA9B32-7881-4404-B5B7-CDE86CCF82F8@sxw.org.uk> Message-ID: <4E4D5BCB.9070604@sinenomine.net> Simon Wilkinson wrote: > As an elector, it would help me in casting my vote if the candidates > would be prepared to say something on the list about their vision for > the standardisation process, what time they are prepared to devote to > the job, and how they think we can best move things forwards. I agree it is a reasonable request, Simon. If I had the opporunity to co-chair the group, firstly I would do my best to provide to the group regular, periodic updates of the work in progress, the status of work in progress, and public and private reminders as needed. I would like to include timelines which should show where we stand on documents to ensure we are moving forward in a timely fashion. I have participated in industry-standard forums in the past, although not related to IETF, and understand the issues of fairness and cooperation which is required to build a consensus. In terms of time, I understand this position will require some time per work week and would be able to dedicate time each week to facilitate the standardization process. Mike -- From gary.buhrmaster@gmail.com Fri Aug 19 07:54:44 2011 From: gary.buhrmaster@gmail.com (Gary Buhrmaster) Date: Thu, 18 Aug 2011 23:54:44 -0700 Subject: [AFS3-std] Re: Voting for the position of AFS3-standardization co-chair In-Reply-To: References: <4E4D1F30.10003@anl.gov> <9CDA9B32-7881-4404-B5B7-CDE86CCF82F8@sxw.org.uk> <4E4D4BA1.8000809@secure-endpoints.com> <20110818134903.a314437f.adeason@sinenomine.net> <20110818140223.c5382fd3.adeason@sinenomine.net> Message-ID: On Thu, Aug 18, 2011 at 11:15, David Boyes wrote: .. > I am suggesting that in the future, the process be changed to require a statement like the one Simon requested from all candidates. In the more formal elections I am familiar with, candidates have the option of offering a statement or to choose to provide none at all. I think that is the appropriate way forward (and the voters will make of those choices by the candidates what they will, as it should be). One alternative might be a (built-in) hold between the candidates being announced and voting beginning to allow the candidates to state their positions on list. Another might be that the chairs ask that as part of the acceptance of the nomination the potential candidate is offered an opportunity to provide a statement that the chair would include in the formal "election has started" email. But that would be for the next election. This election is already in progress. From dboyes@sinenomine.net Fri Aug 19 08:28:58 2011 From: dboyes@sinenomine.net (David Boyes) Date: Fri, 19 Aug 2011 02:28:58 -0500 Subject: [AFS3-std] Re: Voting for the position of AFS3-standardization co-chair In-Reply-To: References: <4E4D1F30.10003@anl.gov> <9CDA9B32-7881-4404-B5B7-CDE86CCF82F8@sxw.org.uk> <4E4D4BA1.8000809@secure-endpoints.com> <20110818134903.a314437f.adeason@sinenomine.net> <20110818140223.c5382fd3.adeason@sinenomine.net> Message-ID: <35BBE9DA-E253-4A01-A02A-B437E3EE6311@sinenomine.net> > One alternative might be a (built-in) hold between > the candidates being announced and voting beginning > to allow the candidates to state their positions on list. > Another might be that the chairs ask that as part > of the acceptance of the nomination the potential > candidate is offered an opportunity to provide a > statement that the chair would include in the > formal "election has started" email. Either of these options seem reasonable for next time. I do still think tha= t if we use them, we should officially add them to the process.= From adeason@sinenomine.net Fri Aug 26 23:29:32 2011 From: adeason@sinenomine.net (Andrew Deason) Date: Fri, 26 Aug 2011 17:29:32 -0500 Subject: [AFS3-std] New version of the 64-bit time I-D (-03) Message-ID: <20110826172932.c2ec883f.adeason@sinenomine.net> draft-deason-afs3-type-time-03 has been posted and is available at This changes the epoch of the absolute time types to the Unix epoch, and changes the names to include '64' in them. Some discussion about differing time granularities and pre-UTC dates has been added. There are a lot of changes between -02 and -03, most of which are just to accommodate the changes in epoch and type names, and other minor stuff like that. While I appreciate feedback on anything in the document, sections 5 (Resolution Limitations) and 6 (Times Before UTC) are completely new, and contain more substantive new text than any other changes. So, if you don't want to read the whole thing again, I'd urge you to at least read those two sections. -- Andrew Deason adeason@sinenomine.net From deengert@anl.gov Mon Aug 29 14:24:53 2011 From: deengert@anl.gov (Douglas E. Engert) Date: Mon, 29 Aug 2011 08:24:53 -0500 Subject: Fwd: [AFS3-std] Voting for the position of AFS3-standardization co-chair Message-ID: <4E5B9325.9020507@anl.gov> This is a reminder, your votes must be in by the end of Thursday 9/1. -------- Original Message -------- Subject: [AFS3-std] Voting for the position of AFS3-standardization co-chair Date: Thu, 18 Aug 2011 09:18:24 -0500 From: Douglas E. Engert To: afs3-standardization@openafs.org CC: Hartmut Reuter , "Douglas E. Engert" http://tools.ietf.org/id/draft-wilkinson-afs3-standardisation-00.txt defines our election procedures to elect a co-chair for a 2 year term starting October 1. In the option of the co-chairs we have two candidates: Jeffrey Hutzelman Mike Meffie Jeff was nominated by Doug Engert and seconded by Matt W. Benjamin. Mike was nominated by Andrew Deason and seconded by Matt Benjamin. I am revising the schedule so voting starts today, and and on September 1. Schedule: Nominations open 8/2 - 8/16 Announcement of nominations 8/18 * revised Voting 8-18 - 9/1 * revised Election results 9/7 Please read section 2.2.2 as to who can vote. Send votes to Hartmut and myself as the vote takers, *NOT* to the list. Please use the subject of this email for voting, you can reply to it, but *NOT* to the full list. -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 _______________________________________________ AFS3-standardization mailing list AFS3-standardization@openafs.org http://lists.openafs.org/mailman/listinfo/afs3-standardization _______________________________________________ AFS3-standardization mailing list AFS3-standardization@openafs.org http://lists.openafs.org/mailman/listinfo/afs3-standardization From deengert@anl.gov Wed Aug 31 21:21:44 2011 From: deengert@anl.gov (Douglas E. Engert) Date: Wed, 31 Aug 2011 15:21:44 -0500 Subject: Fwd: [AFS3-std] Voting for the position of AFS3-standardization co-chair Message-ID: <4E5E97D8.3060204@anl.gov> This is a reminder, you have only one more day to vote. Votes must be received by Thu, 01 Sep 2011 23:59:59 -0500 (CDT) Last year 21 people voted, so far we have received only 10 votes. -------- Original Message -------- Subject: [AFS3-std] Voting for the position of AFS3-standardization co-chair Date: Thu, 18 Aug 2011 09:18:24 -0500 From: Douglas E. Engert To: afs3-standardization@openafs.org CC: Hartmut Reuter , "Douglas E. Engert" http://tools.ietf.org/id/draft-wilkinson-afs3-standardisation-00.txt defines our election procedures to elect a co-chair for a 2 year term starting October 1. In the option of the co-chairs we have two candidates: Jeffrey Hutzelman Mike Meffie Jeff was nominated by Doug Engert and seconded by Matt W. Benjamin. Mike was nominated by Andrew Deason and seconded by Matt Benjamin. I am revising the schedule so voting starts today, and and on September 1. Schedule: Nominations open 8/2 - 8/16 Announcement of nominations 8/18 * revised Voting 8-18 - 9/1 * revised Election results 9/7 Please read section 2.2.2 as to who can vote. Send votes to Hartmut and myself as the vote takers, *NOT* to the list. Please use the subject of this email for voting, you can reply to it, but *NOT* to the full list. -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 _______________________________________________ AFS3-standardization mailing list AFS3-standardization@openafs.org http://lists.openafs.org/mailman/listinfo/afs3-standardization _______________________________________________ AFS3-standardization mailing list AFS3-standardization@openafs.org http://lists.openafs.org/mailman/listinfo/afs3-standardization _______________________________________________ AFS3-standardization mailing list AFS3-standardization@openafs.org http://lists.openafs.org/mailman/listinfo/afs3-standardization