Subject: [provreg] Inconsistent Domain Status Value Guidance in RFC 5731

From: "Hollenbeck, Scott" <[email-masked]>
Date: Fri, 11 Sep 2015 11:28:17 +0000

I received a mail note from someone asking about a difference in the text that appears in RFC 5731 and the schema that is supposed to support that text. First, the text from Section 2.3:

"A domain object MUST always have at least one associated status value".

Text from Section 3.1.2 (info response):

"Zero or more OPTIONAL <domain:status> elements that contain the current status descriptors associated with the domain"

The schema matches the 3.1.2 text. I can't remember why or how we ended up with text that says "MUST always have at least one" in one section and "Zero or more OPTIONAL" in another section. Does this tickle any memories for anyone?

Scott

---

From: "Gould, James" <[email-masked]>
Date: Fri, 11 Sep 2015 11:59:53 +0000

Scott,

It doesn’t “tickle any memories”, but making the status optional (“Zero or more OPTIONAL”) in the info response leaves it up to server policy whether or not to return “the at least one associated status value".   It makes sense in describing the statuses in section 2.3 that there must be at least one status, and leave the return of the statuses optional in the info response based on server policy.  I’m not sure why the server would not want to return the statuses, but the protocol supports such a policy.

—

JG

James Gould
Distinguished Engineer
[email-masked]

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

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

On Sep 11, 2015, at 7:28 AM, Hollenbeck, Scott <[email-masked]<mailto:[email-masked]>> wrote:

Scott

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

---

From: Marc Groeneweg <[email-masked]>
Date: Fri, 11 Sep 2015 12:16:55 +0000

Pfew, Scott,

This goes way back to the original RFC3731, where the exact text exists. I have found an email discussing the status field with zero and more... (sigh, september 2002). 

Regards,
Marc 

-----Original Message-----
From: provreg [mailto:[email-masked]] On Behalf Of Hollenbeck, Scott
Sent: vrijdag 11 september 2015 13:28
To: [email-masked]
Subject: [provreg] Inconsistent Domain Status Value Guidance in RFC 5731

Scott

[email-masked]

Subject: RE: "status" element in <domain:info> response
From: "Liu, Hong <[email-masked]>"
To: "[email-masked]"
Date: Thu, 12 Sep 2002 17:09:30 +0000

Thanks, Scott. That will do it.

-----Original Message-----
From: Hollenbeck, Scott [mailto:[email-masked]]
Sent: Wednesday, September 11, 2002 2:20 PM
To: 'Liu, Hong'; [email-masked]'
Subject: RE: "status" element in <domain:info> response

> <HL>
> Thanks for the clarification. If at least one status tag
> should exist, then
> the example on page 15 as well as the
> domain_info_unauth_result.xml in the
> example package need to be fixed to include at least one status value.
> </HL>

Sigh, you found the spot I forgot that explains why it's OPTIONAL and zero
is possible.  Back to zero being the minimum.

> <HL>
> You are right, not all 17 values are allowed to co-exist at
> the same time
> according to section 2.3. But I am having difficulty
> understanding how 12 is
> derived from the complex rules in section 2.3. Could you
> explain that to me?
> Thanks!
> </HL>

The "pending" status values can't be set if the corresponding "prohibited"
status values are set; all of the "prohibited" values can be set at the same
time.  An object also can't be in both "ok" and any other status at the same
time.  The combination with the greatest number of members is thus:

clientDeleteProhibited
clientHold
clientRenewProhibited
clientTransferProhibited
clientUpdateProhibited
inactive
serverDeleteProhibited
serverHold
serverRenewProhibited
serverTransferProhibited
serverUpdateProhibited

That's 11.  OK, so I missed by one ;-).  I'll check the contact and host
combinations again to be sure they're right, too.

-Scott-

---

From: Roger D Carney <[email-masked]>
Date: Fri, 11 Sep 2015 18:18:24 +0000

+1 Jim, this is how I read it as well and it does make sense to me.  And like Jim, I am not sure why a server would not return the status(es) and we would request that they do, but I do not see a problem with how the RFC is written.

Thanks
Roger

From: provreg [mailto:[email-masked]] On Behalf Of Gould, James
Sent: Friday, September 11, 2015 7:00 AM
To: Hollenbeck, Scott
Cc: [email-masked]
Subject: Re: [provreg] Inconsistent Domain Status Value Guidance in RFC 5731

Scott,

—

JG

James Gould
Distinguished Engineer
[email-masked]

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

Scott

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Fri, 11 Sep 2015 19:20:37 +0000

“Server policy” is a slippery slope when it comes to interoperability. Anyway, I can’t find anything in the email archive that sheds any light on my original question. The text has been consistent since before RFC 3730, so maybe it’s not as confusing as I thought it was this morning.

Scott

From: provreg [mailto:[email-masked]] On Behalf Of Roger D Carney
Sent: Friday, September 11, 2015 2:18 PM
To: [email-masked]
Subject: Re: [provreg] Inconsistent Domain Status Value Guidance in RFC 5731

Thanks
Roger

From: provreg [mailto:[email-masked]] On Behalf Of Gould, James
Sent: Friday, September 11, 2015 7:00 AM
To: Hollenbeck, Scott
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [provreg] Inconsistent Domain Status Value Guidance in RFC 5731

Scott,

—

JG

James Gould
Distinguished Engineer
[email-masked]

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

Scott

---

From: Michael Young <[email-masked]>
Date: Fri, 11 Sep 2015 15:30:09 -0400

Scott I’m not sure (long time ago)  but I think it originally had to do with allowing differing levels of detailed response depending on who was asking - hence server policy.  Seems like it got changed in one spot to allow for that but not another.

-Michael Young

> On Sep 11, 2015, at 3:20 PM, Hollenbeck, Scott <[email-masked]> wrote:
> 
> From: provreg [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Roger D Carney
> To: [email-masked] <mailto:[email-masked]>
> From: provreg [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Gould, James
> Cc: [email-masked] <mailto:[email-masked]>
> [email-masked] <x-msg://42/[email-masked]>
> 
> 703-948-3271
> 12061 Bluemont Way
> Reston, VA 20190
> 
> VerisignInc.com <http://verisigninc.com/>
>  
> On Sep 11, 2015, at 7:28 AM, Hollenbeck, Scott <[email-masked] <mailto:[email-masked]>> wrote:
>  
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/provreg <https://www.ietf.org/mailman/listinfo/provreg>
>  
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/provreg <https://www.ietf.org/mailman/listinfo/provreg>

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Fri, 11 Sep 2015 19:33:43 +0000

I’ll do some more digging on Monday. I see where the change was introduced in draft-ietf-provreg-epp-domain-06; -05 said “One or more OPTIONAL <domain:status> elements” in the info response. So yes, this was a deliberate change, but the document author wasn’t considerate enough to keep a change log in the documents… ;)

Scott

From: Michael Young [mailto:[email-masked]]
Sent: Friday, September 11, 2015 3:30 PM
To: Hollenbeck, Scott
Cc: [email-masked]
Subject: Re: [provreg] Inconsistent Domain Status Value Guidance in RFC 5731

-Michael Young

On Sep 11, 2015, at 3:20 PM, Hollenbeck, Scott <[email-masked]<mailto:[email-masked]>> wrote:

Scott

From: provreg [mailto:[email-masked]] On Behalf Of Roger D Carney
Sent: Friday, September 11, 2015 2:18 PM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [provreg] Inconsistent Domain Status Value Guidance in RFC 5731

Thanks
Roger

Scott,

—

JG

James Gould
Distinguished Engineer
[email-masked]<x-msg://42/[email-masked]>

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

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

Scott

---

From: Geert Debyser <[email-masked]>
Date: Fri, 11 Sep 2015 22:32:50 +0200

Scott,

I also read in the RFC in the same section 2.3:

 -  ok

      This is the normal status value for an object that has no pending
      operations or prohibitions.  This value is set and removed by the
      server as other status values are added or removed.

This makes me consider "ok" as a pseudo status:
"ok" is the default when *no other* statuses are attached,
"ok" is *implicitely* associated in the absence of other statuses.

Zero <domain:status> elements represent the *implicit* nature of the
"ok" status,
hence I don't see a conflict between the two quotes below.

Regards,
Geert

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Mon, 14 Sep 2015 11:09:00 +0000

OK, found it. The thread starts here:

http://www.ietf.org/mail-archive/web/provreg/current/msg01340.html

Summary here:

http://www.ietf.org/mail-archive/web/provreg/current/msg01333.html

Summary: it’s possible for no status values to be returned in an <info> response if the client sending the command isn’t authorized to see the values. Michael was on the right track – thanks.

Scott

From: provreg [mailto:[email-masked]] On Behalf Of Hollenbeck, Scott
Sent: Friday, September 11, 2015 3:34 PM
To: Michael Young
Cc: [email-masked]
Subject: Re: [provreg] Inconsistent Domain Status Value Guidance in RFC 5731

Scott

-Michael Young

Scott

Thanks
Roger

Scott,

—

JG

James Gould
Distinguished Engineer

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

Scott