>Message-ID: <00e701c1d1bb$7f2671c0$7f9d5cc6@UNIR>
>From: "Jim Fleming" <[EMAIL PROTECTED]>
>To: "Richard J. Sexton" <[EMAIL PROTECTED]>
>Cc: "krose@ntia. doc. gov" <[EMAIL PROTECTED]>,
> "ksmith@ntia. doc. gov" <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>,
> <[EMAIL PROTECTED]>, "Simon Higgs" <[EMAIL PROTECTED]>,
> "karl@cavebear. com" <[EMAIL PROTECTED]>,
> "Joanna Lane" <[EMAIL PROTECTED]>, "Jefsey Morfin" <[EMAIL PROTECTED]>,
> "Jay@Fenello. com" <[EMAIL PROTECTED]>, "Ellen Rony" <[EMAIL PROTECTED]>,
> "@Quasar" <[EMAIL PROTECTED]>, "James Love" <[EMAIL PROTECTED]>,
> "ncc" <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>
>References: <[EMAIL PROTECTED]>
>Subject: Raising the Bar, Moving the Goal Posts and Burning the Bridges
>Date: Fri, 22 Mar 2002 10:05:39 -0600
>MIME-Version: 1.0
>Content-Type: text/plain;
> charset="iso-8859-1"
>Content-Transfer-Encoding: 7bit
>X-Priority: 3
>X-MSMail-Priority: Normal
>X-Mailer: Microsoft Outlook Express 5.50.4133.2400
>X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
>
>Note how the U.S. Government helps to raise the bar, and move the goal posts.
>This allows the I* society to burn all of the bridges so that other companies can
>not enter (compete). Once I ran across a little-known U.S. Federal law that
>prohibits U.S. Government employees from working on the development of
>computer protocols. That apparently does not apply to the Internet, or Internet2.
>
>http://www.internet2.edu/ipv6/
>
>http://www.dnso.org/clubpublic/registrars/Arc01/msg02219.html
>
>---------- Forwarded message ----------
>Date: Wed, 20 Mar 2002 17:55:09 -0500
>From: Scott Rose <[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED]
>Subject: Minn provreg meeting notes
>
>Here's the first draft of the meeting minutes from the PROVREG WG.
>Please send any corrections/comments to me. If none, the minutes will
>be submitted to the meeting proceedings.
>
>Gov't in action ;-)
>Scott R.
>
>************************************************************************
>Provreg Meeting minutes
>
>1. WG status (Ed Lewis)
> - Core Documents: In IESG process in various stages
> - Other documents - no discussion
> - 1 Unsolicited individual submission
> - Next target: move core drafts to draft standard as per RFC 2026
> 1. Patrik F: We need 2 independent client and 2 servers to test
>interop.
> (all must work together)
>
>
>2. Last Call Comments on EPP drafts (Scott Hollenbeck)
> - Requirements Draft:
> 1. WG last call completed
> 2. Comments by IESG in Feb, completed in Feb.
> 3. Waiting IESG
> - EPP core drafts
> 1. Last call ends 29 March - few comments for additions or corrections
> - Questions
>Patrik: IESG or AD has not received any more comments than those
>mentioned in the meeting.
>
>
>3. In-process documents
> - BEEP - new revision available in the future.
> 1. Comment: Is anyone planning any implementation on this draft?
> - Container draft - will not be continued.
> - SMTP draft - Still being worked on (rumor). Some interest in seeing
>this as a draft.
> - Push feature draft - missing description document. No one has
> responsibility for that draft. If Push feature is desired, please
>submit an
> individual submission draft.
>
>4. Implementations (about 5 )
> - RTK (Sourceforge project) release Java version of registry tool
> 1. Different releases for different levels of EPP(draft revisions) -
>plan on
> restructuring releases into one package
> - Nominum: .au registry release.
> 1. Adding different extensions than listed in draft
> 2. first country code to use EPP
> - Verisign
> 1. Non-core effort (smaller domains) using EPP for registry
> 2. When EPP reaches RFC status, .com/net/org will go to EPP
> 3. Registry (Verisign) will not hold customer information/contact.
>That will still
> reside at the registrar level.
> 4. All RRP based registration systems will eventually migrate to EPP
>once contract expires
> - .sg registry
> 1. assumed that one status for domain name
> - NIC Mexico:
> 1. looking at rolling EPP out. But using other means to authenticate
>registrar-registrar
> communication
>
>5. Registry-specific extensions (H. Liu)
> - .us TLD implementation for public review
> - Informational - may not be WG draft, but informational as an
>extension to EPP. Test to
> see if EPP really is extensible and still remain interpretational.
> - Differences from draft specs:
> 1. Collect NEXUS info for usTLD registration
> 2. 2 new parameters: AppPurpose and NexusCatagory
> - Alternatives: Name-value pairs or new XML schema definition
> - Comments:
> 1. Where scheme modified? ContactObject extension field
>
>6. Scott H. draft on EPP and DNSSEC/ENUM an individual submission, but
>belongs/will
> remain independent submission (not DNSEXT) and hoped to be
> included in DNSOP WG
> -
>http://www.ietf.org/internet-drafts/draft-hollenbeck-epp-secdns-00.txt
>
>7. Next Steps
> - Need for a BCP/Informational RFC on how these extensions should
>look?
> 1. moved to list
> - Interoperability test: of core protocol specs, not extensions.
> 1. When: wait until we get RFC status - winner
> - No BEEP/SMTP comments
>
>General comments/questions
>1. if we start talking about extensions - rechartering necessary?
>2. Question of "status of command" request message - what it means and
>the status of the draft.
> - Author not present, so no formal answer available.
>
>
>
>
>
--
Clique \Clique\, n. [F., fr. OF. cliquer to click. See Click, v. i.]
A narrow circle of persons associated by common interests or
for the accomplishment of a common purpose; -- generally used
in a bad sense.
[EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
