Subject: Re: [regext] Eric Rescorla's Discuss on draft-ietf-regext-org-11: (with DISCUSS and COMMENT)

From: "Linlin Zhou" <[email-masked]>
Date: Thu, 1 Nov 2018 17:42:52 +0800

Dear Eric,
Sorry for my misunderstanding. Followings are some pseudocode examples for status value changes. But in the real domain business model, there may be other requirement limitations, running code may be different.  Please note that I just listed some major situations, not all of them.

1. organization create

add "pendingCreate"

2. organization update

if ("serverUpdateProhibited" or "pendingDelete" or "pendingUpdate" existed) 
    cannot update
else 
    go 

if ("pendingCreate" existed) 
    can update but no "pendingUpdate" 
else 
    update and add "pendingUpdate"

if ("clientUpdateProhibited" existed) 
    cannot update
else 
    go 

if (recv 'remove clientUpdateProhibited' && other status update commands) 
    cannot update

3. organization delete

if ("clientDeleteProhibited" or "serverDeleteProhibited" or "pendingUpdate" or "pendingDelete" existed)//no pendingCreate 
    cannot delete 
    cannot add "pendingDelete" 

if ("pendingCreate" existed) 
    remove "pendingCreate" 
    add "pendingDelete" 

4. other status actions

if (organization is linked with an EPP object && "clientLinkedProhibited" or "serverLinkedProhibited" not exist) 
    add "linked" 

if (organization status is null || only "linked" existed) 
    add "ok" 
else 
    remove "ok"

Regards,
Linlin

Linlin Zhou
 
From: Eric Rescorla
Date: 2018-10-31 11:23
To: zhoulinlin
CC: regext-chairs; pieter.vandepitte; IESG; regext; draft-ietf-regext-org
Subject: Re: [regext] Eric Rescorla's Discuss on draft-ietf-regext-org-11: (with DISCUSS and COMMENT)

On Tue, Oct 30, 2018 at 7:25 PM Linlin Zhou <[email-masked]> wrote:
Dear Eric,
Please see my feedbaks below.

Regards,
Linlin

Linlin Zhou
----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------
 
Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D3624

This DISCUSS should be easy to clear. I have noted a few points where
I do not believe that the spec is sufficiently clear to implement.
 
DETAIL
S 3.4.
>   
>      o  clientUpdateProhibited, serverUpdateProhibited: Requests to update
>         the object (other than to remove this status) MUST be rejected.
>   
>      o  clientDeleteProhibited, serverDeleteProhibited: Requests to delete
>         the object MUST be rejected.
 
How does access control work here? If either of these values are set,
then it must be rejected?
[Linlin] If you mean that clientUpdateProhibited and serverUpdateProhibited are set, these two statuses can coexist in the system. "clientUpdateProhibited" is set by the client and "serverUpdateProhibited" is set by the server.

That's not what I mean. What I mean is "what is the access control rule that the server is supposed to apply".
[Linlin] The EPP statuses defined in draft-ietf-regext-org follows the model used in the other EPP RFC's, including RFC 5731- RFC 5733. The statuses define the command-level access control rules, where each supported transform command (update and delete) includes a corresponding client-settable ("client") and server-settable ("server") that prohibits execution of the command by the client. The client is allowed make an update only to remove the "clientUpdateProhibited" status when the "clientUpdateProhibited" status is set. Client-specific access control rules (e.g., sponsoring client versus non-sponsoring client) is not defined by the statuses, but is up to server policy.

I'm sorry, but this still isn't clear. Can you perhaps send some pseudocode? 
[Linlin] Our proposal is to add the lead-in bolded text to match the existing EPP RFC's to the Organization mapping. There has been no issues with the interpretation of the statuses with the EPP RFCs, so it's best to match them as closely as possible. In section 3.4,

An organization object MUST always have at least one associated status 
value. Status values can be set only by the client that sponsors an 
organization object and by the server on which the object resides. A 
client can change the status of an organization object using the EPP 
<update> command. Each status value MAY be accompanied by a string 
of human-readable text that describes the rationale for the status 
applied to the object. 

A client MUST NOT alter status values set by the server. A server 
MAY alter or override status values set by a client, subject to local 
server policies. The status of an object MAY change as a result of 
either a client-initiated transform command or an action performed by 
a server operator.

Status values that can be added or removed by a client are prefixed 
with "client". Corresponding status values that can be added or 
removed by a server are prefixed with "server". The "hold" and 
"terminated" status values are server-managed when the organization 
has no parent identifier [Section 3.6] and otherwise MAY be client- 
managed based on server policy. Status values that 
do not begin with either "client" or "server" are server-managed.

Take "clientUpdateProhibited" for example. 
If status value "clientUpdateProhibited" is set by a client 
then <update> command is not allowed to perform by a client 
If status value "clientUpdateProhibited" is removed by a client or a server 
then no limitation of performing EPP commands 

I think we are talking past each other. The question I am asking is what is the access control algorithm for changing other values depending on whether {client,server}UpdateProhibited is set.

-Ekr

---

From: "Gould, James" <[email-masked]>
Date: Wed, 7 Nov 2018 11:30:58 +0000

Eric,

I provide a description of the access control algorithm that is defined in the EPP RFCs (5731-5733) and in draft-ietf-regext-org below:

clientUpdateProhibited Case:

Pre-condition: Organization “res1523” has the clientUpdateProhibited Status

Access Control Algorithm:

If (Organization <update> Command received with only a <org:rem><org:status>clientUpdateProhibited</org:status></org:rem> update) then
            Execute Change
Return Success 1000 “Command completed successfully”
Else // Other updates included with Organization <update> Command
Reject Change
Return 2304 “Object status prohibits operation”

serverUpdateProhibited Case:

Pre-condition: Organization “res1523” has the serverUpdateProhibited Status

Access Control Algorithm:

If (Organization <update> Command received) then
Reject Change
Return 2304 “Object status prohibits operation”

The clientUpdateProhibited status blocks all updates except removing of the clientUpdateProhibited status by the client.  The serverUpdateProhibited status blocks all client updates.  The client cannot set or unset (alter) the server statuses, including the serverUpdateProhibited status.

I hope this helps clarify the EPP access control algorithm that is defined in the EPP RFCs (5731-5733) and in draft-ietf-regext-org.  Let me know if you need any further clarification.

Thanks,

—

JG

James Gould
Distinguished Engineer
[email-masked]

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

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

From: Eric Rescorla <[email-masked]>
Date: Wednesday, October 31, 2018 at 10:24 AM
To: "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, iesg <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: [EXTERNAL] Re: Re: [regext] Eric Rescorla's Discuss on draft-ietf-regext-org-11: (with DISCUSS and COMMENT)
Resent-From: <[email-masked]>
Resent-To: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, James Gould <[email-masked]>
Resent-Date: Wednesday, October 31, 2018 at 10:24 AM

On Tue, Oct 30, 2018 at 7:25 PM Linlin Zhou <[email-masked]<mailto:[email-masked]>> wrote:
Dear Eric,
Please see my feedbaks below.

Regards,
Linlin
________________________________
Linlin Zhou
----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

DETAIL
S 3.4.

-Ekr

S 4.1.2.
>
>      o  One or more <org:status> elements that contain the operational
>         status of the organization, as defined in Section 3.4.
>
>      o  An OPTIONAL <org:parentId> element that contains the identifier of
>         the parent object, as defined in Section 3.6.

It's not clear to me what's really optional here, because you say
above that it's up to the server but then you label some stuff here as
OPTIONAL
[Linlin] If this sentence makes confusion. How about changing it to "It is up to the server policy to decide
what optional attributes will be returned of an organization object." or just remove it?

I don't know, because I don't understand the semantics you are aiming for. Are the other attributes optional.
[Linlin] To be consistent with other EPP RFCs, I suggest removing the sentence "It is up to the server policy to decide what attributes will be returned of an organization object."

Does that mean the other attributes are mandatory? If so, you need to say that.
[Linlin] Yes, thank you.
If the element can appear once, the keyword "OPTIONAL" is used to specify it as an optional element.
If the element can appear multiple times, the word "zero" is used to specify it as an optional element.
Other elements are mandatory.

COMMENT:

S 3.4.
>         has been processed for the object, but the action has not been
>         completed by the server.  Server operators can delay action
>         completion for a variety of reasons, such as to allow for human
>         review or third-party action.  A transform command that is
>         processed, but whose requested action is pending, is noted with
>         response code 1001.

Who can set this?
 [Linlin] The server can set the error code to 1001 and send the response to the client.

Sorry, context got lost. Who can set "pendingCreate"?
[Linlin] PendingCreate or PendingXXX statuses are set by servers.

Then you should say so in the text.
[Linlin] Yes. Please see the above updated text in section 3.4. "Status values that
do not begin with either "client" or "server" are server-managed."

S 3.5.
>         association with another object.  The "linked" status is not
>         explicitly set by the client.  Servers SHOULD provide services to
>         determine existing object associations.
>
>      o  clientLinkProhibited, serverLinkProhibited: Requests to add new
>         links to the role MUST be rejected.

see above question about access control
[Linlin] If both the clientXXXProhibited and serverXXXProhibited are set, this situation is permitted.

Sorry, this is still not clear to me.

[Linlin] Please see the above response.

Sorry, still not clear.
[Linlin] Please see the first issue feedback.

S 4.2.1.
>         status of the organization, as defined in Section 3.4.
>
>      o  An OPTIONAL <org:parentId> element that contains the identifier of
>         the parent object, as defined in Section 3.6.
>
>      o  Zero to two <org:postalInfo> elements that contain postal-address

These rules looks duplicative of <info>. Is there a way to collapse
them?

[Linlin] The attributes need to be defined differently for the create and the info response, since the info response needs to be more flexible with what is returned based on server policy decisions. Yes, they are the same elements, but whether they are required or optional may be different in a create than in a info response. The attributes are duplicated in the other EPP RFCs (RFC 5731 – 5733) for ease in implementation. Attempting to collapse the attributes will make it more difficult for implementors and will not be consistent with the other EPP RFCs.

This is a comment, not a DISCUSS, so you're free to ignore it, but as someone who as implemented quite a few specifications, I don't agree with the claim that it would make things more difficult for implementors. Implementors want to reuse code and if it's a lot of work to see the difference between two parts of the spec, this leads to mistakes.

S 4.2.5.
>      where at least one child element MUST be present:
>
>      o  An OPTIONAL <org:parentId> element that contains the identifier of
>         the parent object...
>
>      o  Zero to two <org:postalInfo> elements that contain postal-address

This also seems duplicative.
[Linlin] Indeed some elements descriptions appear some times in the document. I'd like to have some explanations here again.
This document borrowed the text structure from RFC5731, RFC5732 and RFC5733 of EPP. I think the intension of having some duplicated descriptions is for users' easy reading. When seeing the examples, they do not have to scroll up and down to find the elements definitions. Some descriptions are a little different, although <org:postalInfo> elements appear to be duplicated. Such as, "One or more <org:status> elements" in <info> response and "Zero or more <org:status> elements" in <create> command. Of course putting all the elements definitions in a section is a concise way for the document structure.

It's much harder for implementors because they don't know how to refactor common code.
[Linlin] Duplicating the attributes is needed to address server policy differences between create and the info response, to make it easier for implementors, and to be consistent with the other EPP RFCs (RFC 5731 - RFC 5733).

Again, it's *not* easier for implementors
[Linlin] We want to have this document match what has been done in the other EPP RFCs. People always feel convenient with the existing patterns. As implementers of the EPP RFCs, they have been familiar with the EPP spcifications for years and we believe that it makes things easier for implementers.

-Ekr

---

From: "Gould, James" <[email-masked]>
Date: Wed, 7 Nov 2018 11:39:40 +0000

Benjamin,

This seems overly zealous to the point of being harmful.  For example, if a

server sets the status to "ok", a client cannot replace it by

clientLinkProhibited?

The “ok” status is the default status and not classified as a server status, since it is not prefixed with “server”.  The sentence “A client MUST NOT alter status values set by the server.” means that the client cannot set or remove a server status, such as serverUpdateProhibited.  I hope this clarifies what is defined in the EPP RFCs (5730-5733) and draft-ietf-regext-org.

Thanks,

—

JG

James Gould

Distinguished Engineer

[email-masked]

703-948-3271

12061 Bluemont Way

Reston, VA 20190

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

On 10/31/18, 10:23 AM, "Benjamin Kaduk" <[email-masked]> wrote:

    Trimming to just one potentially problematic suggestion...

    On Wed, Oct 31, 2018 at 10:25:42AM +0800, Linlin Zhou wrote:

    [...]

    > [Linlin] Our proposal is to add the lead-in bolded text to match the existing EPP RFC's to the Organization mapping. There has been no issues with the interpretation of the statuses with the EP…

    [bold does not work super-well in text/plain mail, but

    https://www.ietf.org/mail-archive/web/regext/current/msg01912.html can show

    it]

    > A client MUST NOT alter status values set by the server. A server

    This seems overly zealous to the point of being harmful.  For example, if a

    server sets the status to "ok", a client cannot replace it by

    clientLinkProhibited?

    -Benjamin

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 7 Nov 2018 10:43:42 -0600

[Sorry for the misattribution in the quoting -- the text/plain I'm
responding to did not indicate any quoting at all and I'd probably mess it
up if I tried to manually fix it]

> The “ok” status is the default status and not classified as a server status, since it is not prefixed with “server”.  The sentence “A client MUST NOT alter status values set by the server.” means t…

To be clear, I'm solely commenting on the specific wording -- a "status set
by the server" is a different meaning than a "server status".  In the
dumbest possible reading, the server sets the "ok" status at creation, and
the exact proposed text could be read as denying the client from changing
it.  So, my point is just "be careful about the way you word it".

-Benjamin

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 7 Nov 2018 19:47:30 -0800

OK, so I think the key point here is that either "clientUpdateProhibites"
or "serverUpdateProhibited" will stop both sides from doing updates.

So I think what I would say is somewhere:
Note that if clientUpdateProhibited is set, the client will not be able to
update the object. It will first need to remove that field prior to
attempting to update the object.

Would that work?
-Ekr

On Wed, Nov 7, 2018 at 3:39 AM Gould, James <[email-masked]> wrote:

> The “ok” status is the default status and not classified as a server
> status, since it is not prefixed with “server”.  The sentence “A client
> MUST NOT alter status values set by the server.” means that the client
> cannot set or remove a server status, such as serverUpdateProhibited.  I
> hope this clarifies what is defined in the EPP RFCs (5730-5733) and
> draft-ietf-regext-org.
>
>
>
> Thanks,
>
>
>
> —
>
> JG
>
>
>
>
>
>
>
> James Gould
>
> Distinguished Engineer
>
> [email-masked]
>
>
>
> 703-948-3271
>
> 12061 Bluemont Way
>
> Reston, VA 20190
>
>
>
>     > [Linlin] Our proposal is to add the lead-in bolded text to match the
> existing EPP RFC's to the Organization mapping. There has been no issues
> with the interpretation of the statuses with the EPP RFCs, so it's best to
> match them as closely as possible. In section 3.4,
>
>
>

---

From: "Gould, James" <[email-masked]>
Date: Thu, 8 Nov 2018 07:22:03 +0000

Eric,

No, both statuses only stops the client from doing updates.  The difference is that the server can only set and unset the serverUpdateProhibited status.  The prohibited statuses don’t apply to the server executing the commands.

Based on this, the revised sentence would read:

If clientUpdateProhibited or serverUpdateProhibited is set, the client will not be able to update the object.  For clientUpdateProhibited, the client will first need to remove clientUpdateProhibited prior to attempting to update the object.

Does that help?

—

JG

James Gould
Distinguished Engineer
[email-masked]

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

From: Eric Rescorla <[email-masked]>
Date: Thursday, November 8, 2018 at 10:48 AM
To: James Gould <[email-masked]>
Cc: Benjamin Kaduk <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, IESG <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: [EXTERNAL] Re: Re: Re: [regext] Eric Rescorla's Discuss on draft-ietf-regext-org-11: (with DISCUSS and COMMENT)
Resent-From: <[email-masked]>
Resent-To: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, James Gould <[email-masked]>
Resent-Date: Thursday, November 8, 2018 at 10:48 AM

OK, so I think the key point here is that either "clientUpdateProhibites" or "serverUpdateProhibited" will stop both sides from doing updates.

So I think what I would say is somewhere:
Note that if clientUpdateProhibited is set, the client will not be able to update the object. It will first need to remove that field prior to attempting to update the object.

Would that work?
-Ekr

On Wed, Nov 7, 2018 at 3:39 AM Gould, James <[email-masked]<mailto:[email-masked]>> wrote:

Benjamin,

clientLinkProhibited?

Thanks,

—

JG

James Gould

Distinguished Engineer

[email-masked]

703-948-3271

12061 Bluemont Way

Reston, VA 20190

On 10/31/18, 10:23 AM, "Benjamin Kaduk" <[email-masked]<mailto:[email-masked]>> wrote:

    On Wed, Oct 31, 2018 at 10:25:42AM +0800, Linlin Zhou wrote:

    [...]

    it]

    clientLinkProhibited?

    -Benjamin

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 7 Nov 2018 23:29:31 -0800

On Wed, Nov 7, 2018 at 11:22 PM Gould, James <[email-masked]> wrote:

> Eric,
>
>
>
> No, both statuses only stops the client from doing updates.  The
> difference is that the server can only set and unset the
> serverUpdateProhibited status.  The prohibited statuses don’t apply to the
> server executing the commands.
>
>
>
> If clientUpdateProhibited or serverUpdateProhibited is set, the client
> will not be able to update the object.  For clientUpdateProhibited, the
> client will first need to remove clientUpdateProhibited prior to attempting
> to update the object.
>

> Does that help?

Yes. Could you add a sentence that says that the server can modify anything
at any time?

In any case, I think we're on the same page. I'll clear my DISCUSS and
trust you to update.

Thanks,
-Ekr

—
>
>
>
> JG
>
>
>
>
> *James Gould *Distinguished Engineer
> [email-masked]
>
> 703-948-3271
> 12061 Bluemont Way
> Reston, VA 20190
>
> *From: *Eric Rescorla <[email-masked]>
> *Date: *Thursday, November 8, 2018 at 10:48 AM
> *To: *James Gould <[email-masked]>
> *Cc: *Benjamin Kaduk <[email-masked]>, "[email-masked]" <
> [email-masked]>, "[email-masked]" <[email-masked]>, "
> [email-masked]" <[email-masked]>, IESG <
> [email-masked]>, "[email-masked]" <[email-masked]>, "
> [email-masked]" <[email-masked]>
> *Subject: *[EXTERNAL] Re: Re: Re: [regext] Eric Rescorla's Discuss on
> draft-ietf-regext-org-11: (with DISCUSS and COMMENT)
> *Resent-From: *<[email-masked]>
> *Resent-To: *<[email-masked]>, <[email-masked]>, <
> [email-masked]>, <[email-masked]>, James Gould <[email-masked]>
> *Resent-Date: *Thursday, November 8, 2018 at 10:48 AM
>
>
>

---

From: "Gould, James" <[email-masked]>
Date: Thu, 8 Nov 2018 07:31:21 +0000

Benjamin,

How about the following clarifying changes?

Client status values that can be added or removed by a client are prefixed
with "client".  Corresponding server status values that can be added or
removed by a server are prefixed with "server".

And

A client MUST NOT alter server status values set by the server.

—

JG

James Gould

Distinguished Engineer

[email-masked]

703-948-3271

12061 Bluemont Way

Reston, VA 20190

On 11/7/18, 11:43 PM, "Benjamin Kaduk" <[email-masked]> wrote:

    -Benjamin

---

From: "Gould, James" <[email-masked]>
Date: Thu, 8 Nov 2018 07:35:58 +0000

Eric,

Yes, that can be done, with one small change of “anything” to “the object” to be consistent with the subject of the modification.  The complete revised text is:

If clientUpdateProhibited or serverUpdateProhibited is set, the client will not be able to update the object.  For clientUpdateProhibited, the client will first need to remove clientUpdateProhibited prior to attempting to update the object.  The server can modify the object at any time.

—

JG

James Gould
Distinguished Engineer
[email-masked]

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

From: Eric Rescorla <[email-masked]>
Date: Thursday, November 8, 2018 at 2:30 PM
To: James Gould <[email-masked]>
Cc: Benjamin Kaduk <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, IESG <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: [EXTERNAL] Re: Re: Re: Re: [regext] Eric Rescorla's Discuss on draft-ietf-regext-org-11: (with DISCUSS and COMMENT)

On Wed, Nov 7, 2018 at 11:22 PM Gould, James <[email-masked]<mailto:[email-masked]>> wrote:
Eric,

Does that help?

Yes. Could you add a sentence that says that the server can modify anything at any time?

In any case, I think we're on the same page. I'll clear my DISCUSS and trust you to update.

Thanks,
-Ekr

—

JG

James Gould
Distinguished Engineer
[email-masked]<http://[email-masked]>

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

From: Eric Rescorla <[email-masked]<mailto:[email-masked]>>
Date: Thursday, November 8, 2018 at 10:48 AM
To: James Gould <[email-masked]<mailto:[email-masked]>>
Cc: Benjamin Kaduk <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, IESG <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [EXTERNAL] Re: Re: Re: [regext] Eric Rescorla's Discuss on draft-ietf-regext-org-11: (with DISCUSS and COMMENT)
Resent-From: <[email-masked]<mailto:[email-masked]>>
Resent-To: <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, James Gould <[email-masked]<mailto:[email-masked]>>
Resent-Date: Thursday, November 8, 2018 at 10:48 AM

Would that work?
-Ekr

Benjamin,

clientLinkProhibited?

Thanks,

—

JG

James Gould

Distinguished Engineer

[email-masked]

703-948-3271

12061 Bluemont Way

Reston, VA 20190

    On Wed, Oct 31, 2018 at 10:25:42AM +0800, Linlin Zhou wrote:

    [...]

    it]

    clientLinkProhibited?

    -Benjamin

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 7 Nov 2018 23:40:06 -0800

LGTM. I have already cleared my DISCUSS

-Ekr

On Wed, Nov 7, 2018 at 11:36 PM Gould, James <[email-masked]> wrote:

> Eric,
>
>
>
> Yes, that can be done, with one small change of “anything” to “the object”
> to be consistent with the subject of the modification.  The complete
> revised text is:
>
>
>
> to update the object.  The server can modify the object at any time.
>
>
>
>
>
> —
>
>
>
> JG
>
>
>
>
> *Date: *Thursday, November 8, 2018 at 2:30 PM
> *Subject: *[EXTERNAL] Re: Re: Re: Re: [regext] Eric Rescorla's Discuss on

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 8 Nov 2018 03:52:28 -0600

Hi James,

> A client MUST NOT alter server status values set by the server.

That works for me.  Thank you for fine-tuning the wording.

-Benjamin