IETF Logo Mail Archive

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

Roger D Carney <rcarney@godaddy.com> Fri, 11 September 2015 18:18 UTC

Return-Path: <rcarney@godaddy.com>
X-Original-To: provreg@ietfa.amsl.com
Delivered-To: provreg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A22DD1ACCC7 for <provreg@ietfa.amsl.com>; Fri, 11 Sep 2015 11:18:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3aks9bxvKQcY for <provreg@ietfa.amsl.com>; Fri, 11 Sep 2015 11:18:30 -0700 (PDT)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0101.outbound.protection.outlook.com [65.55.169.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D76C1B3011 for <provreg@ietf.org>; Fri, 11 Sep 2015 11:18:28 -0700 (PDT)
Received: from BY2PR0201MB0773.namprd02.prod.outlook.com (10.160.125.139) by BY2PR0201MB0773.namprd02.prod.outlook.com (10.160.125.139) with Microsoft SMTP Server (TLS) id 15.1.262.15; Fri, 11 Sep 2015 18:18:25 +0000
Received: from BY2PR0201MB0773.namprd02.prod.outlook.com ([10.160.125.139]) by BY2PR0201MB0773.namprd02.prod.outlook.com ([10.160.125.139]) with mapi id 15.01.0262.011; Fri, 11 Sep 2015 18:18:25 +0000
From: Roger D Carney <rcarney@godaddy.com>
To: "provreg@ietf.org" <provreg@ietf.org>
Thread-Topic: [provreg] Inconsistent Domain Status Value Guidance in RFC 5731
Thread-Index: AdDshPQ1r2kOebPHS1yh9BbwRNMx5wAJfG4AAANH0kA=
Date: Fri, 11 Sep 2015 18:18:24 +0000
Message-ID: <BY2PR0201MB077366BD965352C103CA8B97B1500@BY2PR0201MB0773.namprd02.prod.outlook.com>
References: <831693C2CDA2E849A7D7A712B24E257F4A082789@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <7EAA9955-6334-49AB-9294-49B8B50A2C23@verisign.com>
In-Reply-To: <7EAA9955-6334-49AB-9294-49B8B50A2C23@verisign.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=rcarney@godaddy.com;
x-originating-ip: [64.202.161.57]
x-microsoft-exchange-diagnostics: 1; BY2PR0201MB0773; 5:d+Hc0DmgOCoDpK7ghgpw2gE2Jn/YJIyLEDmT387OCCO6J1+rSaMRPAFX2r903xrAkFhWiBjb6y0syp+Zly50O6hm9TXZL9yMaET1Rd6n0sbxvfUbl9iV+ISR1J8shGoYeiaEAa6E+t9OGd1xWrY7cg==; 24:sW8igxjFySelz1mP2Swoi8kfGaphIoatE1HKhZ5if3UJEO0neUP87/gheq5839nPTfPFutvZppbXA+bH1eIeehUstAkSpxRhg9HeNxUt9jI=; 20:uw5akjAHrB6GFnbhWs6lqpei33/nhOEVa8Dspy+gJXdss0EBfK/aZ0gV21oQI2k8oXoH80rfmWLNMVfYFptn9Q==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR0201MB0773;
x-microsoft-antispam-prvs: <BY2PR0201MB07732ABFBDD985F4C3EC9A78B1500@BY2PR0201MB0773.namprd02.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(108003899814671);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(8121501046)(5005006)(3002001); SRVR:BY2PR0201MB0773; BCL:0; PCL:0; RULEID:; SRVR:BY2PR0201MB0773;
x-forefront-prvs: 06968FD8C4
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(199003)(377454003)(189002)(24454002)(45074003)(81156007)(99286002)(86362001)(110136002)(5001830100001)(97736004)(92566002)(19627595001)(102836002)(76576001)(50986999)(15975445007)(5003600100002)(19580405001)(19580395003)(77096005)(2501003)(19300405004)(5001860100001)(99936001)(11100500001)(2950100001)(16601075003)(66066001)(450100001)(87936001)(46102003)(77156002)(68736005)(122556002)(2351001)(19617315012)(10400500002)(2900100001)(5004730100002)(62966003)(76176999)(54356999)(106356001)(105586002)(189998001)(4001540100001)(5007970100001)(74316001)(19625215002)(5001960100002)(33656002)(16236675004)(40100003)(17760045003)(64706001)(5002640100001)(101416001)(107886002)(18206015028)(7099028)(579004); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR0201MB0773; H:BY2PR0201MB0773.namprd02.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:;
received-spf: None (protection.outlook.com: godaddy.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/related; boundary="_004_BY2PR0201MB077366BD965352C103CA8B97B1500BY2PR0201MB0773_"; type="multipart/alternative"
MIME-Version: 1.0
X-OriginatorOrg: godaddy.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Sep 2015 18:18:24.8735 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: d5f1622b-14a3-45a6-b069-003f8dc4851f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR0201MB0773
Archived-At: <http://mailarchive.ietf.org/arch/msg/provreg/Jmw5iqWUrUDdlYghAWbsnXHhoEo>
Subject: Re: [provreg] Inconsistent Domain Status Value Guidance in RFC 5731
X-BeenThere: provreg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: EPP discussion list <provreg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/provreg>, <mailto:provreg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/provreg/>
List-Post: <mailto:provreg@ietf.org>
List-Help: <mailto:provreg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/provreg>, <mailto:provreg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 11 Sep 2015 18:18:32 -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:provreg-bounces@ietf.org] On Behalf Of Gould, James
Sent: Friday, September 11, 2015 7:00 AM
To: Hollenbeck, Scott
Cc: provreg@ietf.org
Subject: Re: [provreg] Inconsistent Domain Status Value Guidance in RFC 5731

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

[cid:image001.png@01D0EC74.59B59BE0]

James Gould
Distinguished Engineer
jgould@Verisign.com

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

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

On Sep 11, 2015, at 7:28 AM, Hollenbeck, Scott <shollenbeck@verisign.com<mailto:shollenbeck@verisign.com>> wrote:

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

_______________________________________________
provreg mailing list
provreg@ietf.org<mailto:provreg@ietf.org>
https://www.ietf.org/mailman/listinfo/provreg

v2.23.0 | Report a Bug | By Email