Subject: Re: [regext] I-D Action: draft-ietf-regext-epp-fees-03.txt

From: "Gould, James" <[email-masked]>
Date: Thu, 27 Apr 2017 19:55:54 +0000

Roger,

Thanks for posting the updated draft and the draft looks very close to what was discussed in Chicago.  Below is my feedback to the latest version:

1.      Section 3.1 “Client Commands”

a.       It may be useful to include an enumerated list of commands that is extensible like what was done in draft-ietf-regext-change-poll, which includes an enumerated list of operations with one of the values being “custom” and with an optional “op” attribute to define the custom operation name.  This way the XML parser will validate the command names prior to hitting the business logic, except for the “custom” command that would need to be manually validated.

2.      Section 5.1.1 “EPP <check> Command”

a.       The OPTOINAL <fee:period> element should be fully defined.  For example, what happens if the <fee:period> is not provided?  I assume that if the <fee:period> is not provided that the default period would be used.  The default period may be dependent on the command itself.  For example, a restore does not have a period and therefore there is no default.  Should the default period be defined by command in the protocol, or should it be up to server policy?  My thought is to leave it up to server policy, since that is what was done in EPP RFC 5732.

b.      The OPTIONAL <fee:class> element should be fully defined.  What does providing the <fee:class> mean.  Is the <fee:class> a filter to indicate whether the domain name matches the specified classification?  If the <fee:class> does not match, is the fee returned as unavailable due to something like “mismatching class”?  Since classification is handled at the object level and not the command level, does it make sense to set it at the object level in the XML, like placing it at the level of the <fee:currency> and the <fee:command> elements instead of placing it under the <fee:command> element?  The same holds true for the check response extension.

c.       I would not directly refer to the <domain:name> or the <domain:check> except as an example, since the fee extension could be applied to other billable EPP objects (e.g., email forwarding, defensive registration).  My recommendation is to be generic in stating something like “and a <fee:cd> for each element referenced in the check command, like for each <domain:name> element in RFC 5731 [RFC5731]”.  Similarly, I would change “A <fee:objID> element, which MUST match an element name from the client command, like the <domain:name> element in RFC 5731 [RFC5731]”.

d.      I would update the text for the <fee:period> returned in the check response extension.  I would keep the text generic to return the period that was requested in the command extension, the default period if there is one for the command, or no period if the command is not associated with a period like with the “restore” command in RFC 3915 [RFC3915].  Since we can create new verbs in EPP like what was done with the “restore” command in RFC 3915, I recommend keeping the language in the extension as generic as possible to cover the full set of options for any type of command.

e.       I recommend describing the <fee:fee>, <fee:credit>, <fee:class>, and <fee:reason> elements either directly with the element or via a reference to somewhere else within the draft.

f.        The <check> response example is missing the “avail” attribute in the <fee:cd> elements when avail=”1”.  I realize that the default is “1” in the XML schema, so I would specify that there is a default value of “1” in the text and I would include examples of explicitly including the avail=”1” for clarity.

g.      You may need to support the “lang” attribute for the <fee:reason> to be consistent with the other EPP RFCs.

h.      In the example, I don’t believe any <fee:cd> elements other than <fee:objID> and <fee:reason> would be returned when avail=”0”.  I recommend removing the <fee:period> from the example when avail=”0”.

i.        I believe it is important to include text describing how a compliant server should handle non-standard fee objects in the check command when the fee extension is not passed.  It is best to return the non-standard fee object as unavailable in the check response.  If the client does not know the fee, then the create will fail downstream, so it’s best to address it upfront.

3.      Section 5.1.1.1 “Server Handling of Elements”

a.       I believe the first element on the tiers of classes, it looks like it assumes that the avail flag is at the level of the <fee:command> element, but it is now at the level of <fee:cd>.  My recommendation is to define the <fee:class> at the object level, and if the <fee:class> does not match, return avail=”0” at the <fee:cd> level with a <fee:reason> “fee class mismatch”.

b.      The second element also assumes that the avail flag is at the <fee:command> level.  This element is not clear to me.  I believe in general if the <fee:class> is passed it must be validated as a supported classification and compared with the classification assigned to the object, and if the classification is invalid or there is a mismatch the fee should be returned as unavailable (avail=”0”) for the fee object with a reason.

c.       I’m not sure that it’s good for the server to ignore an element passed by the client.  If the client passes an invalid element, then it should return as unavailable with a reason.

—

JG

James Gould
Distinguished Engineer
[email-masked]

703-948-3271
12061 Bluemont Way
Reston, VA 20190

VerisignInc.com<http://verisigninc.com/>

From: regext <[email-masked]> on behalf of Roger Carney <[email-masked]>
Date: Tuesday, April 25, 2017 at 5:40 PM
To: "[email-masked]" <[email-masked]>
Subject: [EXTERNAL] Re: [regext] I-D Action: draft-ietf-regext-epp-fees-03.txt

Good Afternoon,

Here is the update draft document. This should include all of the agreed upon changes from the Chicago meeting (biggest change was the simplification of the <check> call).

One topic that was discussed in Chicago (and not resolved) was on the concept of “premium names” and what is returned from the server if no fee extension was passed into the <check>. Many thought to be more “backwards compatible”/”user friendly”, especially for those registrars that do not and may not be participating in the allocation of “premium names”, that the server should respond as unavailable. Others expressed that if it is available then the server should respond available. Please share your thoughts on the list on this topic and if this draft should even try to account for this concept.

Please let me know if you have any questions.

Thanks

Roger

-----Original Message-----
From: regext [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Tuesday, April 25, 2017 4:31 PM
To: [email-masked]
Cc: [email-masked]
Subject: [regext] I-D Action: draft-ietf-regext-epp-fees-03.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.

This draft is a work item of the Registration Protocols Extensions of the IETF.

        Title           : Registry Fee Extension for the Extensible Provisioning Protocol (EPP)

        Authors         : Roger Carney

                          Gavin Brown

                          Jothan Frakes

                Filename        : draft-ietf-regext-epp-fees-03.txt

                Pages           : 33

                Date            : 2017-04-25

Abstract:

   This document describes an Extensible Provisioning Protocol (EPP)

   extension mapping for registry fees.

The IETF datatracker status page for this draft is:

https://datatracker.ietf.org/doc/draft-ietf-regext-epp-fees/

There are also htmlized versions available at:

https://tools.ietf.org/html/draft-ietf-regext-epp-fees-03

https://datatracker.ietf.org/doc/html/draft-ietf-regext-epp-fees-03

A diff from the previous version is available at:

https://www.ietf.org/rfcdiff?url2=draft-ietf-regext-epp-fees-03

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:

ftp://ftp.ietf.org/internet-drafts/

_______________________________________________

regext mailing list

[email-masked]<mailto:[email-masked]>

https://www.ietf.org/mailman/listinfo/regext

---

From: Thomas Corte <[email-masked]>
Date: Fri, 28 Apr 2017 14:09:51 +0200

Hello,

On 27/04/2017 21:55, Gould, James wrote:

> ...
> h.      In the example, I don’t believe any <fee:cd> elements other than
> <fee:objID> and <fee:reason> would be returned when avail=”0”.  I
> recommend removing the <fee:period> from the example when avail=”0”.   

Overall, I'm a bit puzzled regarding the usefulness of the "avail"
attribute at this level, especially since the <cd> element still requires
at least one command to be specified. The change log says

"Moved fee avail to objectCDType to allow fast failing on error situations."

However, if e.g. the domain name is invalid for the TLD, the XSD still
demands to include at least one command, meaning that all commands from
the check request would have to echoed here for no good reason. "command"
in objectCDType should IMO have minOccurs="0". Even better, there should
be a <choice> between a sequence of <command> or <reason> in the XSD
(either there are available commands, or there's a reason why they're not
available).

I'm also wondering how to report a wrong currency with this new version.
I think the only way to deal with it is to let the entire <epp:check>
fail with an error, since there's no way to (briefly) report a wrong
currency due to the way objectCDType is currently defined.

I don't think the "fast fail" objective was reached in this regard.

Best regards,

Thomas

-- 
TANGO REGISTRY SERVICES® is a product of:
Knipp Medien und Kommunikation GmbH
Technologiepark                             Phone: +49 231 9703-222
Martin-Schmeisser-Weg 9                       Fax: +49 231 9703-200
D-44227 Dortmund                       E-Mail: [email-masked]
Germany

---

From: "Gould, James" <[email-masked]>
Date: Fri, 28 Apr 2017 12:32:44 +0000

Thomas,

I don’t agree that failing the entire check command if someone passes invalid input in the fee extension, unless it is syntactically incorrect.  The point is to communicate whether the fee information is available for the given object and commands, and if it is return the fee information.  I agree that there should be a choice between inclusion of the commands or the reason in “objectCDType” to support returning either a successful list of commands or optionally providing a reason that the fee information is not available.  My recommendation for “objectCDType” is below:

    <complexType name="objectCDType">
      <sequence>
        <element name="objID" type="fee:objectIdentifierType" />
        <choice minOccurs=”0”>
          <element name="command" type="fee:commandType"
            maxOccurs="unbounded" />
          <element name="reason" type="eppcom:reasonType”/>
        </choice>
      </sequence>
      <attribute name="avail" type="boolean" use=”required” />
    </complexType>

The objectCDType can include the fee:objID, the fee:objID along with the commands, or the fee:objID along with the reason.  The “avail” flag is changed to required without a default to be explicit, which is consistent with how the “avail” flag works in the check response.  The reason leverages the “eppcom:reasonType” to support use of the optional “lang” attribute to be consistent with the check response.  
  
—
 
JG

James Gould
Distinguished Engineer
[email-masked]

703-948-3271
12061 Bluemont Way
Reston, VA 20190

VerisignInc.com <http://verisigninc.com/> 

On 4/28/17, 8:09 AM, "Thomas Corte" <[email-masked]> wrote:

    Hello,

    

    

    Best regards,
    
    Thomas

---

From: Thomas Corte <[email-masked]>
Date: Fri, 28 Apr 2017 14:48:20 +0200

Hello James,

On 28/04/2017 14:32, Gould, James wrote:

> Thomas,
> 
> I don’t agree that failing the entire check command if someone passes invalid input in the fee extension, unless it is syntactically incorrect.  The point is to communicate whether the fee information is available for the given object and commands, and if it is return the fee information.

Sure, but the current draft would require the following response for a
<check> with a wrong currency "BLA", assuming that two domains with 3
commands each were specified:

      <chkData xmlns="urn:ietf:params:xml:ns:fee-0.17">
        <currency>BLA</currency>
        <cd avail="false">
          <objID>example1.tld</objID>
          <command name="create" phase="open">
            <period unit="y">2</period>
            <reason>the selected currency is not supported (supported
currency is "USD")</reason>
          </command>
          <command name="transfer" phase="open">
            <period unit="y">1</period>
            <reason>the selected currency is not supported (supported
currency is "USD")</reason>
          </command>
          <command name="renew" phase="open">
            <period unit="y">1</period>
            <reason>the selected currency is not supported (supported
currency is "USD")</reason>
          </command>
        </cd>
        <cd avail="false">
          <objID>example1.tld</objID>
          <command name="create" phase="open">
            <period unit="y">2</period>
            <reason>the selected currency is not supported (supported
currency is "USD")</reason>
          </command>
          <command name="transfer" phase="open">
            <period unit="y">1</period>
            <reason>the selected currency is not supported (supported
currency is "USD")</reason>
          </command>
          <command name="renew" phase="open">
            <period unit="y">1</period>
            <reason>the selected currency is not supported (supported
currency is "USD")</reason>
          </command>
        </cd>
      </chkData>

I.e. there is no shorter way to report the wrong currency (which should
have prevented any further checks by the server whatsoever) than this.
Note that the periods are there since the draft says "The <fee:period>
element MUST be present in <check> responses."

It gets a bit better by introducing the <choice> we discussed (see
below), but even then the response would have to list each domain from
the check, even though the error is independent from the domain name.
Yet I'm aware that the only option to prevent this would be to introduce
a framing element for the <cd> elements, which could then contain (yet
another) reason for failure as an alternative for the <cd> children.

> I agree that there should be a choice between inclusion of the commands or the reason in “objectCDType” to support returning either a successful list of commands or optionally providing a reason that the fee information is not available.  My recommendation for “objectCDType” is below:
> 

Agreed, this is what I had in mind.

However, the question from the e-mail I sent yesterday remains - how to
report "mixed" results (i.e., what value should "avail" have if fees are
available for some nested commands, but not for others (see the example
from my e-mail).

Best regards,

Thomas

-- 
____________________________________________________________________
     |       |
     | knipp |            Knipp  Medien und Kommunikation GmbH
      -------                    Technologiepark
                                 Martin-Schmeißer-Weg 9
                                 44227 Dortmund
                                 Deutschland

     Dipl.-Informatiker          Tel:    +49 231 9703-0
     Thomas Corte                Fax:    +49 231 9703-200
     Stellvertretender Leiter    SIP:    [email-masked]
     Software-Entwicklung        E-Mail: [email-masked]

                                 Registereintrag:
                                 Amtsgericht Dortmund, HRB 13728

                                 Geschäftsführer:
                                 Dietmar Knipp, Elmar Knipp

---

From: "Gould, James" <[email-masked]>
Date: Fri, 28 Apr 2017 13:27:16 +0000

Thomas,

There are three classifications of errors that can occur with the fee extension to the check command:

1.       Syntax error – This should result in an error for the entire check command.

2.       Object (domain) name error (incorrect domain name, reserved domain name, blocked domain name, etc.) – This should result in returning avail=”0” for the associated fee:cd element for the object in the response.

3.       Crosscutting input element error (invalid currency, invalid command, invalid command period, invalid class, invalid command phase or invalid subphase – Since each of these input elements apply to all objects in the check command, an error with any of them will impact the ability to return a complete set of fee information.  My recommendation is to fast fail the processing of the fee information and return back avail=”0” for each of the objects in the response with an appropriate reason like “Invalid currency XXX”, “Invalid command XXX”, or “Invalid command XXX period YYY”.  I don’t believe that it will help to attempt to put a higher level avail attribute and reason for the entire fee check response extension, since the client would be expecting a fee result for each object in the check command on a successful response.  The check command should not fail based on a data issue, so I would apply that same approach with the fee extension to the check command.

a.       Since we’re extending the check command and response, I don’t believe that the processing should flag errors below the object level.  This means that if one command is valid and another command is invalid, the fee information is not available for the object.  The server will fast fail the processing of the fee extension in the event of a failure to one command, class, period, phase, subphase, or currency.  If there is an expectation that the server should not fast fail, then we should consider adding or moving the fee extension to the info command and response.

—

JG

James Gould

Distinguished Engineer

[email-masked]

703-948-3271

12061 Bluemont Way

Reston, VA 20190

On 4/28/17, 8:48 AM, "Thomas Corte" <[email-masked]> wrote:

    Hello James,

            <currency>BLA</currency>

            <cd avail="false">

              </command>

              </command>

              </command>

            </cd>

            <cd avail="false">

              </command>

              </command>

              </command>

            </cd>

          </chkData>

    from my e-mail).

    Best regards,

    Thomas

    --

         |       |

          -------                    Technologiepark

                                     Martin-Schmeißer-Weg 9

                                     44227 Dortmund

                                     Deutschland

                                     Registereintrag:

                                     Geschäftsführer:

---

From: Thomas Corte <[email-masked]>
Date: Fri, 28 Apr 2017 16:09:52 +0200

James,

On 28/04/2017 15:27, Gould, James wrote:

> 2.       Object (domain) name error (incorrect domain name, reserved
> domain name, blocked domain name, etc.) – This should result in returning
> avail=”0” for the associated fee:cd element for the object in the response.

Agreed.

>  My recommendation
> is to fast fail the processing of the fee information and return back
> avail=”0” for each of the objects in the response with an appropriate
> reason like “Invalid currency XXX”, “Invalid command XXX”, or “Invalid
> command XXX period YYY”.  I don’t believe that it will help to attempt to
> put a higher level avail attribute and reason for the entire fee check
> response extension, since the client would be expecting a fee result for
> each object in the check command on a successful response.  The check
> command should not fail based on a data issue, so I would apply that same
> approach with the fee extension to the check command. 
> 
> a.       Since we’re extending the check command and response, I don’t
> believe that the processing should flag errors below the object level. 
> This means that if one command is valid and another command is invalid,
> the fee information is not available for the object.  The server will
> fast fail the processing of the fee extension in the event of a failure
> to one command, class, period, phase, subphase, or currency.  If there is
> an expectation that the server should not fast fail, then we should
> consider adding or moving the fee extension to the info command and
> response.   

Agreed, even if the response would in this case not really reflect the
server's internal fast failure, since it would still return the same
error message for each checked object. But I can live with that.

The question remains how to respond in situations where, for the same
name, some <command> report assessed fees (since the name is e.g. OK for
a certain phase or period), but some others have a <reason> indicating an
error.
Which value should the <cd> element's "attribute" have? Here's the
example from yesterday's e-mail again:

 <chkData xmlns="urn:ietf:params:xml:ns:fee-0.17">
        <currency>EUR</currency>
        <cd avail="???">
          <objID>example.tld</objID>
          <command name="create" phase="open">
            <period unit="y">1</period>
            <fee applied="immediate"
              description="domain creation in phase 'open'"
grace-period="PT1M" refundable="true">60.00</fee>
          </command>
          <command name="create" phase="custom" subphase="defensive">
            <period unit="y">1</period>
            <fee applied="immediate"
              description="domain creation in phase
'defensive-registration'"
              grace-period="PT1M" refundable="true">30.00</fee>
          </command>
          <command name="create" phase="custom" subphase="promotion">
            <reason>domain name not available as a promotion name</reason>
          </command>
        </cd>
      </chkData>

My suggestion would be to always include all <command> results in the
<cd> element (whether they have fees or reason), and to have <cd
avail="true"> as long as at least one <command> does not have a <reason>
indicating an error. I.e., only if all the <command> elements in the
response contain a reason indicating an error, the <cd> element should
indicate the non-availability of fees.

Thoughts?

Best regards,

Thomas

---

From: Jody Kolker <[email-masked]>
Date: Fri, 28 Apr 2017 19:41:34 +0000

Thanks James.

Comments in line below.

From: regext [mailto:[email-masked]] On Behalf Of Gould, James
Sent: Thursday, April 27, 2017 2:56 PM
To: Roger D Carney <[email-masked]>; [email-masked]
Subject: Re: [regext] I-D Action: draft-ietf-regext-epp-fees-03.txt

Roger,

This section appears to be enumerated already but does need to have the “custom” command added.  Can you be provide an example of the enumeration?

The <fee:period> is defined in 3.3 – should that text also be added to 5.1.1?
From the document:
The <fee:period> element is OPTIONAL in <check> commands: if omitted,the server MUST determine the fee(s) using a validity period of 1 year.  The <fee:period> element MUST be present in <check> responses.

I believe the <fee:class> should be removed from the check command request as it does not seem to have a purpose.  It should only be included in the response.

Will review with Roger.

Will review with Roger.

Will review with Roger.

Agree.

Could this be left to server preference?

Agree – If the fee extension is not passed in the check command for a domain that is non standard pricing, the check command should return unavailable for backwards compatibility for registrars that will not be selling premium domains.  To these registrars these domains are not available to be registered.

If the <fee:class> is removed from the request, this would not be an issue.  I recommend removing <fee:class> from the check request.

Let’s remove <fee:class> from the check request.

—

JG

James Gould
Distinguished Engineer
[email-masked]

703-948-3271
12061 Bluemont Way
Reston, VA 20190

From: regext <[email-masked]<mailto:[email-masked]>> on behalf of Roger Carney <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, April 25, 2017 at 5:40 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [EXTERNAL] Re: [regext] I-D Action: draft-ietf-regext-epp-fees-03.txt

Good Afternoon,

Thanks

Roger

-----Original Message-----
From: regext [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Tuesday, April 25, 2017 4:31 PM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: [regext] I-D Action: draft-ietf-regext-epp-fees-03.txt

        Authors         : Roger Carney

                          Gavin Brown

                          Jothan Frakes

                Pages           : 33

                Date            : 2017-04-25

Abstract:

regext mailing list

---

From: "Gould, James" <[email-masked]>
Date: Fri, 28 Apr 2017 20:55:55 +0000

Thomas,

I’m sorry, I missed the existence of a reason under the command since I thought the “avail” attribute and the reason element moved from the command level to the object level.  My main concern with providing a highly feature rich fee extension to the domain check is ensuring that the domain check continues to meet the performance requirements, and that we don’t start down the path of creating extension upon extension of the domain check that will transition it into a domain “everything” command.  I view the options for providing fee information in the fee extension as follows:

1.       Extend the check command, as defined in draft-ietf-regext-epp-fees-03, with object level availability and unavailability reasons.

a.       Your use case would be handled by returning <cd avail=”0”> for example.tld with no commands and with the reason “domain name not available as a promotion name”.  The server would fast fail the fee extension for the domain example.tld.  This keeps the check command lighter weight, but it is still much heavier weight than a standard check command.

2.       Extend the check command by defining a new command called the “fee check command”.

a.       The “fee check command” can include the availability along with the fee information, but it is treated differently from a standard check command and future extensions of the check command would not automatically apply to the “fee check command”.  This change is strictly associated with the wording in the draft like defining the “claims check command” in section 3.1.1 of draft-ietf-regext-launchphase.  In this case, we can provide for a more robust set of features targeted to the fee, which could include extension level availability (currency is invalid or some other crosscutting attribute), object level availability (domain name is invalid or class is invalid), and command level availability (command is invalid or command not applicable to domain).  This removes the concern over the performance of the check command, since this is a fee check command and it does not encourage future heavyweight extensions.

3.       Implement #1 and extend the info command by defining a new command called the “fee info command” that supports getting fee information for existing and non-existing objects, but it does not return the standard info response.

a.       The fee info command could include a more robust set of features targeted to the fee, which could include extension level availability (currency is invalid or some other crosscutting attribute), object level availability (domain name is invalid or class is invalid), and command level availability (command is invalid or command not applicable to domain).  This supports getting more complex fee information without making the check command too complex.  An example of a similar info command extension is defined with the Related Domain Info Command in our Related Domain Extension (http://www.verisign.com/assets/epp-sdk/verisign_epp-extension_related-domain_v00.html#relatedInfoForm ).

Thoughts?

—

JG

James Gould

Distinguished Engineer

[email-masked]

703-948-3271

12061 Bluemont Way

Reston, VA 20190

On 4/28/17, 10:09 AM, "Thomas Corte" <[email-masked]> wrote:

    James,

    > There are three classifications of errors that can occur with the fee

    > extension to the check command:

    > 1.       Syntax error – This should result in an error for the entire

    > check command.

    Agreed.

    error.

            <currency>EUR</currency>

            <cd avail="???">

                <fee applied="immediate"

              </command>

                <fee applied="immediate"

              </command>

              </command>

            </cd>

          </chkData>

    Thoughts?

    Best regards,

    Thomas

    --

    Germany

---

From: Rubens Kuhl <[email-masked]>
Date: Fri, 28 Apr 2017 18:14:06 -0300

James, 

I understand your concern with option #1, but I think option #3 goes into a different set of issues where we mix the domain sales pipeline with domain management activities, for which domain:info is commonly used. 
I'm neutral between option #1 and option #2, but while both work me, I would really like to know which option has more chance of being implemented by registrars; and if they favor either #1 or #2, I would favor that as well. 

Rubens

> Em 28 de abr de 2017, à(s) 17:55:000, Gould, James <[email-masked]> escreveu:
> 
> Thomas, 
>  
> a.       The fee info command could include a more robust set of features targeted to the fee, which could include extension level availability (currency is invalid or some other crosscutting attribute), object level availability (domain name is invalid or class is invalid), and command level availability (command is invalid or command not applicable to domain).  This supports getting more complex fee information without making the check command too complex.  An example of a similar info command extension is defined with the Related Domain Info Command in our Related Domain Extension (http://www.verisign.com/assets/epp-sdk/verisign_epp-extension_related-domain_v00.html#relatedInfoForm <http://www.verisign.com/assets/epp-sdk/verisign_epp-extension_related-domain_v00.html#relatedInfoForm> ).  
>  
> Thoughts?
>  
> —
> JG
>  
>  
>  
> James Gould
> Distinguished Engineer
> [email-masked] <mailto:[email-masked]>
>  
> 703-948-3271
> 12061 Bluemont Way
> Reston, VA 20190
>  
> VerisignInc.com <http://verisigninc.com/> <http://verisigninc.com/ <http://verisigninc.com/>> 
>  
> [email-masked]