Re: Launch Phase EPP Extension Version 08

James,

I realize that there are many ways to tackle a dutch auction, but the reason that I brought it up was that I wanted to bring up a use case where a landrush resulted in registrations instead of applications.  The phase should not imply either the creation of registrations or applications.   A dutch action is a form of a launch phase, so I believe that the launch extension is applicable and can handle it independent of a custom extension.

With your text suggestion "domain:create commands without the launch:create extension MAY be rejected by servers, where their processing results in an application object. Servers SHOULD reject commands where the value of the phase element does not match a phase supported by the server", you are proposing to leave it up to server policy?  Why would it make a difference if the resulting object was a registration or application?  Are you thinking that the most likely failure scenario is when the client is expecting the registry active phase to be "open", but instead the active phase is "landrush" that results in an unexpected application?  What about the dutch auction use case without the use of a custom extension?  Shouldn't the server fail the command if the phase passed does not match the active phase as opposed to a non-supported phase?


JG

[cid:27D96FDA-5E3E-4F7E-A432-F6A8404C7099]

James Gould
Principal Software Engineer
[email protected]

703-948-3271 (Office)
12061 Bluemont Way
Reston, VA 20190
VerisignInc.com

From: James Mitchell <[email protected]<mailto:[email protected]>>
Date: Monday, April 1, 2013 8:13 PM
To: James Gould <[email protected]<mailto:[email protected]>>, Ben Levac <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, Alexander Mayrhofer <[email protected]<mailto:[email protected]>>, Seth Goldman <[email protected]<mailto:[email protected]>>
Cc: EPP Provreg <[email protected]<mailto:[email protected]>>
Subject: Re: [provreg] Launch Phase EPP Extension Version 08

Jim,

There are many ways to skin a cat, and there are many ways to run a dutch auction. For example we would probably use our "premium-name" extension where a registrar acknowledges the transaction price in the create command and leave the launch-1.0 extension out of it.

A registry may run both applications and registrations at the same time, such as during the launch of a set of new names post GA (previously withheld names, new IDN table release). We feel the distinction between applications and direct registrations is therefore required. This however can probably be achieved with creates for the launch names resulting in failure unless a "custom" phase is supplied.

FWIW, we will implement Option #3. I suggest text along the lines of the following should suffice: "domain:create commands without the launch:create extension MAY be rejected by servers, where their processing results in an application object. Servers SHOULD reject commands where the value of the phase element does not match a phase supported by the server".

Regards,
James

From: <Gould>, James <[email protected]<mailto:[email protected]>>
Date: Tuesday, 2 April 2013 9:21 AM
To: Ben Levac <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, Alexander Mayrhofer <[email protected]<mailto:[email protected]>>, Seth Goldman <[email protected]<mailto:[email protected]>>
Cc: "EPP Provreg ([email protected]<mailto:[email protected]>)" <[email protected]<mailto:[email protected]>>
Subject: Re: [provreg] Launch Phase EPP Extension Version 08

Ben,

The dutch auction would be first-come-first-serve and would charge different prices (higher prices earlier) to mitigate a blast of registrations up front, so a dutch auction would result in registrations and not applications.  I never proposed requiring the create type (application or registration), but to make it an optional property that explicitly defines the intent of the client and that the server can validate against the type of object that will be created.  The create type and the phase defined in option 2 both may be passed based on the preference of the registrar and validated by the server.  The most likely time for the landrush will be during the claims1 phase, so technically the extension can include the claims information if required.  As posted earlier, what is the desired mechanism to reflect the phase for landrush during claims1 (e.g. claims1 with landrush sub-phase or landrush with claims1 sub-phase)?  My recommendation would be to define the phase as claim1 with landrush as a sub-phase, since claims1 defines the most impactful interface with the claims check and additional information required on create.

Option 2 with required server validation accomplishes everything for registrars that intend to always pass the additional information (phase, sub-phase, create type).  A registrar can pick which information they want to be validated by the server based on their business practices ahead of the server accepting the create.  I believe we are in agreement with the original issue of being able to pass the <launch:create> extension without the mark or notice information.  I believe that we are in agreement that the server must validate the information passed.  The only item that is being actively debated is the text of whether the client must or may pass the extension.

Do any registrars or registries have an issue with requiring the launch extension on create for all non-open (GA) launch phases?  Do any registrars see use for passing the create type (application or registration) with the <launch:create> extension to explicitly define the intended type of object to create?

Thanks,

--

JG

[cid:28154F51-F225-47D4-8D33-B0226D8C773F]

James Gould
Principal Software Engineer
[email protected]<mailto:[email protected]>

703-948-3271 (Office)
12061 Bluemont Way
Reston, VA 20190
VerisignInc.com

From: Ben Levac <[email protected]<mailto:[email protected]>>
Date: Monday, April 1, 2013 5:46 PM
To: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, James Gould <[email protected]<mailto:[email protected]>>, Alexander Mayrhofer <[email protected]<mailto:[email protected]>>, Seth Goldman <[email protected]<mailto:[email protected]>>
Cc: EPP Provreg <[email protected]<mailto:[email protected]>>
Subject: RE: [provreg] Launch Phase EPP Extension Version 08

Jeremy,

I think we both agree on the proposal:

- *require* the launch phase to be submitted for every phase preceding GA.
    - registry will report failure if the requested phase is not currently operational
- *don't require* any additional elements besides launch phase during landrush

James,

I must say that I’m not familiar with Dutch auctions or how they would work in the context of landrush.  I don’t see how simply passing in a mandatory launch phase for “landrush” would prevent Dutch auctions from working.  If the issue is with the object type being passed in as initially suggested in option 3, then I agree with Jeremy, let’s not require that information.

Cheers,

Ben

From:[email protected]<mailto:[email protected]> [mailto:[email protected]]
Sent: Monday, April 01, 2013 1:33 PM
To: Gould, James; Ben Levac; Alexander Mayrhofer; Seth Goldman
Cc: EPP Provreg ([email protected]<mailto:[email protected]>)
Subject: RE: [provreg] Launch Phase EPP Extension Version 08

Here are the most compelling factors for us:


1. We prefer the ability to explicitly state the phase when sending a create command (only options 2 and 3 provide that).  Upon reading your response, Ben, I do see your point about the value of requiring (vs merely allowing) the launch phase, in that it will guard against a possible registrar error condition where a general registration request is sent during landrush.  We've coded bugs in the past, and we certainly will in the future, and this extra mechanism to guard against our own fallibility now seems prudent to me.  That said, I'm open to making the launch phase either optional or required, but I'm now leaning slightly toward required.


2. We prefer *not* to submit an additional attribute to specify the intent (registration/application), as it seems unnecessary - I don't recall any single launch phase for any TLD where both synchronous and asynchronous methods were supported in that single phase, and the idea that any of the new gTLDs would feature a single launch phase that simultaneously supports both synchronous and asynchronous create commands seems to only add confusion.  Therefore, it seems to me that specifying the phase would be explicit enough.  Option 3 (as Jim defined in his post Thursday, March 28, 2013 1:20 PM) requires this additional attribute to be sent, which is why I did not previously choose option 3, as presented by Jim originally.


3. Server validation is certainly a great help to the registrar, so we appreciate all the suggestions that have been shared so far in that regard.  Whether we settle on optional or required phase (and sub-phase, if appropriate) information, we appreciate knowing that even the optional elements are being validated.


So, while the polls are still open, if I could suggest an option 2.5 that would satisfy the factors listed above, it would be:


- *require* the launch phase to be submitted for every phase preceding GA.
    - registry will report failure if the requested phase is not currently operational
- *don't require* any additional elements besides launch phase during landrush


Thanks,
Jeremy Bushlack
GoDaddy.com<http://GoDaddy.com>
[email protected]<mailto:[email protected]>
http://www.godaddy.com
319-294-3934

I value service, simplicity, and facts. How am I doing? Reply to my supervisor, Roger Carney ([email protected]<mailto:[email protected]>).

-------- Original Message --------
Subject: Re: [provreg] Launch Phase EPP Extension Version 08
From: "Gould, James" <[email protected]<mailto:[email protected]>>
Date: Mon, April 01, 2013 2:57 pm
To: Ben Levac <[email protected]<mailto:[email protected]>>,
"[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, Alexander
Mayrhofer <[email protected]<mailto:[email protected]>>, Seth Goldman
<[email protected]<mailto:[email protected]>>
Cc: "EPP Provreg ([email protected]<mailto:[email protected]>)" <[email protected]<mailto:[email protected]>>
Ben,

Just to be clear, option 3 means that the registrar must pass the extension for all applicable non-open launch phases  (sunrise, landrush, claims1, claims2, and custom) and the server will fail the command if it does not match the active phase.  The landrush phase does not automatically indicate that it will create an application, since a server could use a dutch auction for the landrush, so the landrush create could result in a registration instead of an application.  I believe that it's best to go with option 2, since it supports registrars that do want to explicitly specify the phase but it does not require it if the registrar does not want the validation done.  The server should validate the information passed (phase, sub-phase, application or registration) against the active phase, sub-phase, and resulting create type (application or registration), and it can be made a must in the extension.  What do you think of not requiring it to be passed, but requiring the server validation of what is passed?

--

JG

[cid:[email protected]]

James Gould
Principal Software Engineer
[email protected]<mailto:[email protected]>

703-948-3271 (Office)
12061 Bluemont Way
Reston, VA 20190
VerisignInc.com<http://VerisignInc.com>

From: Ben Levac <[email protected]<mailto:[email protected]>>
Date: Monday, April 1, 2013 3:15 PM
To: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, Alexander Mayrhofer <[email protected]<mailto:[email protected]>>, James Gould <[email protected]<mailto:[email protected]>>, Seth Goldman <[email protected]<mailto:[email protected]>>
Cc: EPP Provreg <[email protected]<mailto:[email protected]>>
Subject: RE: [provreg] Launch Phase EPP Extension Version 08

Thank you for your response Jeremy.  It’s great to get the registrar perspective on this issue.

Just to be clear, option 2 does not “enforce” passing the extension as you drew it out below.   It just says that as a registrar, you are free to pass that extension or not.  But if you do NOT pass it during the landrush phase, then the request would still be successful, and you would have you would end up with an application, whether you intended to get a GA registration or a landrush application.

Option 3 says that you should always pass the extension below if you are trying to register a landrush application.  Otherwise you will get a server error.  That way, if a request for a domain registration is sent in error during the landrush phase, you would not be accidentally register the application.

Our main worry is that in an environment where a large number of TLDs are coming on board every week, if there is ever an error made by a registrar regarding the start of Landrush versus GA and they start sending domain registration commands during the landrush phase, there would be nothing stopping those commands from succeeding.

If you  “prefer to be explicit about the action we are asking the registry to take.”, then it sounds like option 3 is also better from your perspective?

Cheers,

Ben

From:[email protected]<mailto:[email protected]> [mailto:[email protected]]
Sent: Monday, April 01, 2013 11:52 AM
To: Alexander Mayrhofer; Gould, James; Seth Goldman; Ben Levac
Cc: EPP Provreg ([email protected]<mailto:[email protected]>)
Subject: RE: [provreg] Launch Phase EPP Extension Version 08

This registrar's preference is option 2.  We prefer to be explicit about the action we are asking the registry to take.  Past experience with TLD launches has shown that landrush and GA generally function quite differently, so it seems that there should be a way to distinguish between a request for a landrush launch:create and a GA create, so we desire the ability to pass in a landrush application as follows, without any additional required elements:

<extension>
    <launch:create>
        <launch:phase>landrush</launch:phase>
        <!-- nothing additional required here -->
    </launch:create>
</extension>

For our systems, the introduction of an object type indicator (application/registration) is not necessary.  If it were optional in the spec, I'm not certain that we'd use it.  I liked Ben's previous statement: "We don’t intend to support  more than one type (application/registration) per phase, so I don’t see the need to make the object type element (or attribute) mandatory."  Further, we will be parsing the create:response for a 1000 or 1001 as well to confirm that the action that we expected is the action that was performed.

I also agree with the registrar that Seth mentioned regarding the importance of an OTE environment that supports all launch phases.


Thanks,
Jeremy Bushlack
GoDaddy.com<http://GoDaddy.com>
[email protected]<mailto:[email protected]>
http://www.godaddy.com
319-294-3934
We're hiring!<http://x.co/openings>

I value service, simplicity, and facts. How am I doing? Reply to my supervisor, Roger Carney ([email protected]<mailto:[email protected]>).

-------- Original Message --------
Subject: Re: [provreg] Launch Phase EPP Extension Version 08
From: Alexander Mayrhofer <[email protected]<mailto:[email protected]>>
Date: Sun, March 31, 2013 3:06 pm
To: "Gould, James" <[email protected]<mailto:[email protected]>>, Seth Goldman
<[email protected]<mailto:[email protected]>>, Ben Levac <[email protected]<mailto:[email protected]>>
Cc: "EPP Provreg ([email protected]<mailto:[email protected]>)" <[email protected]<mailto:[email protected]>>
Option #1 would definitely also work for us, since we try to keep the set of EPP extensions / features as simple as possible [Sadly, often enough *technical* availability of a certain feature tends to *triggers* unneccessary creativity in policy-land :-/ ]. Option #3 is hence undesirable for us.

Alex


Von: Gould, James [mailto:[email protected]]
Gesendet: Freitag, 29. März 2013 16:47
An: Alexander Mayrhofer; Seth Goldman; Ben Levac
Cc: EPP Provreg ([email protected]<mailto:[email protected]>)
Betreff: Re: [provreg] Launch Phase EPP Extension Version 08

I believe that for option #2 it is truly optionally for the Registrars, where if the Registrar wants to ensure that the server validates their intent ahead of accepting the transaction, then they can pass the extension.  By default the server will apply the rules of the active phase and will create the object type (registration or application) of the active phase.  An example I have of specifying the phase is if a launch used a dutch auction, where sub-phases represented the price bands, by default the Registrar would get the active price at the time of the transaction.  If the Registrar wanted to ensure that they got the registration at the desired price band, then they can pass the phase (with the specific sub-phase) that would be validated by the server prior to allowing the transaction to go through.  The option of specifying the type of object (registration or application) is just an indication of the intent of the Registrar, that if it does not match what the server will do, can fast fail.

From what I understand option #2 is preferred.  Does anyone disagree with including option #2 in the draft?

Our hope was to stabilize the draft with the 08 draft, but this change obviously requires an 09 draft.  Since the door is open, are there any other desired changes that should be included in the 09 draft?  We really need to lock it down to support the implementations, so please review the draft and recommend any changes now.

Thanks,

--

JG

[cid:[email protected]]

James Gould
Principal Software Engineer
[email protected]<mailto:[email protected]>

703-948-3271 (Office)
12061 Bluemont Way
Reston, VA 20190
VerisignInc.com<http://VerisignInc.com>

From: Alexander Mayrhofer <[email protected]<mailto:[email protected]>>
Date: Friday, March 29, 2013 10:52 AM
To: Seth Goldman <[email protected]<mailto:[email protected]>>, Ben Levac <[email protected]<mailto:[email protected]>>
Cc: EPP Provreg <[email protected]<mailto:[email protected]>>
Subject: Re: [provreg] Launch Phase EPP Extension Version 08

I’m with Seth and Ben. #2 is the most flexible solution.

My concern is that „most flexible“ also means „most potential for confusion“. Registrars will have to deal with a lots of (different) phases with hundreds of registries, and they might lose business just because they failed to „label“ a certain transaction with the correct phase. Registries would also need to define policy for the case when the phase is not identified, so the question of whether or not to „auto-detect“ the correct phase needs to be solved in both options #1 and #2. Option #2 allows in addition, however, transactions without a phase identifier to be rejected.

Alex.

Von:[email protected]<mailto:[email protected]> [mailto:[email protected]] Im Auftrag von Seth Goldman
Gesendet: Freitag, 29. März 2013 15:37
An: Ben Levac
Cc: EPP Provreg ([email protected]<mailto:[email protected]>)
Betreff: Re: [provreg] Launch Phase EPP Extension Version 08

We also prefer #2. It leaves it open for server policy to dictate whether they require clients to specify it or not, so it's the most flexible.

On Thu, Mar 28, 2013 at 5:50 PM, Ben Levac <[email protected]<mailto:[email protected]>> wrote:
James, Seth,

We prefer option #2.    We don’t intend to support  more than one type (application/registration) per phase, so I don’t see the need to make the object type element (or attribute) mandatory.  We would have to come up with a mechanism to make the mark or notice information optional though.

Cheers,

Ben

From: Gould, James [mailto:[email protected]<mailto:[email protected]>]
Sent: Thursday, March 28, 2013 1:20 PM
To: Seth Goldman
Cc: Ben Levac; EPP Provreg ([email protected]<mailto:[email protected]>)

Subject: Re: [provreg] Launch Phase EPP Extension Version 08

Seth,

I believe that the server will support only an application or a registration, but not both,  during a particular phase.  The creation of an application by the server will be indicated by the return of the 1001 result code and the creation of a registration by the server will be indicated by the return of a 1000 result code.  This is the same behavior when dealing with registries that do or don't support the pendingCreate in RFC 5731.  With support of the launch extension, the create response will return the launch extension with the application identifier for an application as well.  The question is whether the client should or be required to explicitly pass the launch extension with the applicable launch phase when the mark or notice is not needed.  If so, should the client also explicitly specify whether the intent is to create an application or a registration.  If the active phase of the server does not support the intent of the client (phase and application/registration) the server should fail the command.  As defined now, the client can not pass the launch extension  when the mark or notice is not required on create, and the server will create the appropriate object (application or registration) based on the active phase.

Should we do the following:

  1.  Leave the draft, where the client only passes the extension when the mark or notice information is needed.  The server will create the appropriate object (application or registration) based on the active phase and return the appropriate result code (1001 or 1000) and optionally with the launch phase extension.
  2.  Update the draft to support the option for the client to explicitly define the intended phase and optionally the intended object type (application or registration) in the extension to create.  The server will fail the command if the specified phase does not match and the specified object type does not match.
  3.  Update the draft to require the client to explicitly define the intended phase and intended object type (application or registration) in the extension to create.  The server will fail the command if the specified phase does not match and the specified object type does not match.
I prefer #1 and between #2 and #3, I prefer #2.

Are there any other options that should be considered?  Which option is preferred?

Thanks,


--

JG

[cid:[email protected]]

James Gould
Principal Software Engineer
[email protected]<mailto:[email protected]>

703-948-3271 (Office)
12061 Bluemont Way
Reston, VA 20190
VerisignInc.com<http://VerisignInc.com>

From: Seth Goldman <[email protected]<mailto:[email protected]>>
Date: Thursday, March 28, 2013 3:31 PM
To: James Gould <[email protected]<mailto:[email protected]>>
Cc: Ben Levac <[email protected]<mailto:[email protected]>>, EPP Provreg <[email protected]<mailto:[email protected]>>
Subject: Re: [provreg] Launch Phase EPP Extension Version 08

True, the phase may not be sufficient. I guess there are three possible values here:

  1.  Create an application for this domain, otherwise fail.
  2.  Allocate this domain, otherwise fail.
  3.  Allocate this domain if possible; otherwise create an application.
If registrars are fine with 3) being the default behavior, then there's no need for them to signal their intent. If they would ever want 1) or 2), though, then we should make their intent explicit. I was imagining they 1) or 2) to be desireable because 3) seems like a bad customer experience. But I'm just speculating, and I don't have any special insight here.

On Thu, Mar 28, 2013 at 3:13 PM, Gould, James <[email protected]<mailto:[email protected]>> wrote:
Seth & Ben,

Being explicit is certainly good.  Do the Registrars have an issue with the registries requiring the extension to be passed as a form of signaling the intent for creates during the launch phases?  If so, should an element or attribute be added on the create to indicate whether the intent is to create an application or registration?  The phase alone might not define the intent.


--

JG

[cid:[email protected]]

James Gould
Principal Software Engineer
[email protected]<mailto:[email protected]>

703-948-3271 (Office)
12061 Bluemont Way
Reston, VA 20190
VerisignInc.com<http://VerisignInc.com>

From: Seth Goldman <[email protected]<mailto:[email protected]>>
Date: Thursday, March 28, 2013 12:49 PM
To: Ben Levac <[email protected]<mailto:[email protected]>>
Cc: James Gould <[email protected]<mailto:[email protected]>>, EPP Provreg <[email protected]<mailto:[email protected]>>

Subject: Re: [provreg] Launch Phase EPP Extension Version 08

I think the extension would be preferable. It can serve as a signal of intent from the registrar that they know exactly what phase they're applying for. I could perhaps envision a scenario where there's some intercommunication between the registry and registrar on the ending time of sunrise, and the registrar ends up creating an application instead of an allocated registration on create.

On Thu, Mar 28, 2013 at 12:36 PM, Ben Levac <[email protected]<mailto:[email protected]>> wrote:
James,

In an environment where multiple TLDs are hosted on the same server, where TLDs can be in different phases, then it might seem like a good idea to ask the registrar to pass in the <lauch:create> extension to confirm that they know what they are asking for (sunrise application vs landrush application vs registration).  And it might not only be for landrush, but some registries may have multiple sunrise periods where the second sunrise is based on other criteria (belonging to an organization, or to a group for example), and not on Mark data.

But I also realize that making the <choice> optional means that we can't rely on XML validation to ensure that those elements are passed for regular ICANN mandated sunrise periods.

I would be interested to hear from other registries planning on running landrush phases and whether they feel that an extension would be preferable or not.

Cheers,

Ben

-----Original Message-----
From: Gould, James [mailto:[email protected]<mailto:[email protected]>]
Sent: Thursday, March 28, 2013 9:21 AM
To: Ben Levac; EPP Provreg ([email protected]<mailto:[email protected]>)
Subject: Re: [provreg] Launch Phase EPP Extension Version 08

Ben,

If the registry does not require any additional launch information from the client on the create (mark or notice), then the extension does not need to be passed.  By making the mark or notice optional on the create, the only element passed would be the phase.  Do you believe that passing the phase and requirement the extension will help in the contract between the client and the server for a non-sunrise phase where a notice is not required?  I recommend only adding the extension when it is needed.

--

JG



James Gould
Principal Software Engineer
[email protected]<mailto:[email protected]>

703-948-3271 (Office)
12061 Bluemont Way
Reston, VA 20190
VerisignInc.com<http://VerisignInc.com>





On 3/28/13 12:02 PM, "Ben Levac" <[email protected]<mailto:[email protected]>> wrote:

>Guys,
>
>Thank you for the updated spec.
>
>One small comment.  If a registry wishes to use the <launch:create>
>extension for landrush, the schema forces us to pass either of
><launch:codeMark>, <smd:signedMark>, <smd:encodedSignedMark> or
><launch:notice>.  However, in most cases, I assume that registries
>would not expect any Mark information, and for most cases, no notice
>information during the landrush period.  Could we not make those pieces
>of information optional by adding a minOccurs = 0 to the choice element?
>
>I guess another option would be to NOT require the <launch:create> in
>landrush since no other pieces of information are required... However,
>I feel that it is nice to require it because it confirms that the
>registrar knows that he's submitting a domain application as opposed to
>a domain registration.
>
>Cheers,
>
>Ben Levac
>
>-----Original Message-----
>From: [email protected]<mailto:[email protected]> [mailto:[email protected]<mailto:[email protected]>] On
>Behalf Of Gould, James
>Sent: Thursday, March 28, 2013 6:58 AM
>To: EPP Provreg ([email protected]<mailto:[email protected]>)
>Subject: [provreg] Launch Phase EPP Extension Version 08
>
>Wil Tan, Gavin Brown and I have updated the Launch Phase EPP Extension
>Mapping to Version 08.  You can find the draft at the URL
>http://tools.ietf.org/html/draft-tan-epp-launchphase-08.  This version
>includes the following changes:
>
>   1.  Added support for use of the launch statuses and poll messaging
>for Launch Registrations based on feedback from Sharon Wodjenski and
>Trung Tran.
>   2.  Incorporated changes based on updates or clarifications in
>draft-lozano-tmch-func-spec-01
><http://tools.ietf.org/html/draft-lozano-tmch-func-spec-01>, which
>include:
>       1.  Removed the unused <launch:generatedDate> element.
>       2.  Removed the <launch:source> element.
>       3.  Added the <launch:notAfter> element based on the required
><tmNotice:notAfter> element.
>
>We are hoping that the draft can be stabilized to help with the
>implementations.  Please reply with any feedback.
>
>Thanks,
>
>JG
>
>James F. Gould
>Verisign
>
>
>_______________________________________________
>provreg mailing list
>[email protected]<mailto:[email protected]>
>https://www.ietf.org/mailman/listinfo/provreg
>
>Please NOTE: This electronic message, including any attachments, may
>include privileged, confidential and/or inside information owned by
>Demand Media, Inc. Any distribution or use of this communication by
>anyone other than the intended recipient(s) is strictly prohibited and
>may be unlawful.  If you are not the intended recipient, please notify
>the sender by replying to this message and then delete it from your
>system. Thank you.
>_______________________________________________
>provreg mailing list
>[email protected]<mailto:[email protected]>
>https://www.ietf.org/mailman/listinfo/provreg


Please NOTE: This electronic message, including any attachments, may include privileged, confidential and/or inside information owned by Demand Media, Inc. Any distribution or use of this communication by anyone other than the intended recipient(s) is strictly prohibited and may be unlawful.  If you are not the intended recipient, please notify the sender by replying to this message and then delete it from your system. Thank you.
_______________________________________________
provreg mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/provreg



________________________________
Please NOTE: This electronic message, including any attachments, may include privileged, confidential and/or inside information owned by Demand Media, Inc. Any distribution or use of this communication by anyone other than the intended recipient(s) is strictly prohibited and may be unlawful. If you are not the intended recipient, please notify the sender by replying to this message and then delete it from your system. Thank you.

________________________________
_______________________________________________
provreg mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/provreg

________________________________
Please NOTE: This electronic message, including any attachments, may include privileged, confidential and/or inside information owned by Demand Media, Inc. Any distribution or use of this communication by anyone other than the intended recipient(s) is strictly prohibited and may be unlawful. If you are not the intended recipient, please notify the sender by replying to this message and then delete it from your system. Thank you.

________________________________
Please NOTE: This electronic message, including any attachments, may include privileged, confidential and/or inside information owned by Demand Media, Inc. Any distribution or use of this communication by anyone other than the intended recipient(s) is strictly prohibited and may be unlawful. If you are not the intended recipient, please notify the sender by replying to this message and then delete it from your system. Thank you.

_______________________________________________
provreg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/provreg