Re: [eppext] Last Call: <draft-ietf-eppext-keyrelay-10.txt> (Key Relay Mapping for the Extensible Provisioning Protocol) to Proposed Standard

I think that's a good fix, Rik.

Scott

> On Nov 24, 2015, at 3:31 AM, Rik Ribbers <rik.ribbers@sidn.nl> wrote:
> 
> Hello All,
> 
> Based on the discussion the reseller drafts within the EPPEXT working group I revisited the keyrelay draft and came to the conclusion I want to change something in the XML schema. As it is in last call I post this message in the IETF list and the WG list.
> 
> What is the issue:
> In this thread there is a discussion on the XML schema attribute schemaLocation.   
> https://www.ietf.org/mail-archive/web/eppext/current/msg00841.html 
> 
> Having read the XML schema specification this attribute can be used in a document to provide hints as to the physical location of schema documents which may be used for assessment. In other words it is optional and is treated as a hint for XML parsers. We have added the schemaLocation to the XSDs in our own SRS implementation for XML validation and that's how it ended op in the keyrelay document.
> 
> Looking at the other EPP RFC (RFC5731,RFC5732,RFC5733) there is no schemaLocation attribute in the XML schema, so my proposal below makes the keyrelay document more in sync with the existing RFCs.
> 
> My proposal is to change the following in Chapter 4 Formal syntax:
> 
>   <import namespace="urn:ietf:params:xml:ns:epp-1.0"
>       schemaLocation="epp-1.0.xsd" />
>     <import namespace="urn:ietf:params:xml:ns:eppcom-1.0"
>       schemaLocation="eppcom-1.0.xsd" />
>     <import namespace="urn:ietf:params:xml:ns:secDNS-1.1"
>       schemaLocation="secdns-1.1.xsd" />
>     <import namespace="urn:ietf:params:xml:ns:domain-1.0"
>       schemaLocation="domain-1.0.xsd" />
> 
> into
> 
>   <import namespace="urn:ietf:params:xml:ns:epp-1.0"/>
>   <import namespace="urn:ietf:params:xml:ns:eppcom-1.0"/>
>   <import namespace="urn:ietf:params:xml:ns:secDNS-1.1"/>
>   <import namespace="urn:ietf:params:xml:ns:domain-1.0"/>
> 
> Is there any objection to doing this? Any other remarks?
> 
> Kind regards,
> Rik Ribbers
> 
> 
> 
>> On 20 Nov 2015, at 22:05, The IESG <iesg-secretary@ietf.org> wrote:
>> 
>> 
>> The IESG has received a request from the Extensible Provisioning Protocol>> Extensions WG (eppext) to consider the following document:
>> - 'Key Relay Mapping for the Extensible Provisioning Protocol'
>> <draft-ietf-eppext-keyrelay-10.txt> as Proposed Standard
>> 
>> The IESG plans to make a decision in the next few weeks, and solicits
>> final comments on this action. Please send substantive comments to the
>> ietf@ietf.org mailing lists by 2015-12-04. Exceptionally, comments may be>> sent to iesg@ietf.org instead. In either case, please retain the
>> beginning of the Subject line to allow automated sorting.
>> 
>> Abstract
>> 
>> 
>>  This document describes an Extensible Provisioning Protocol (EPP)
>>  mapping for a key relay object that relays DNSSEC key material
>>  between EPP clients using the poll queue defined in RFC5730.
>> 
>>  This key relay mapping will help facilitate changing the DNS operator
>>  of a domain while keeping the DNSSEC chain of trust intact.
>> 
>> 
>> 
>> 
>> The file can be obtained via
>> https://datatracker.ietf.org/doc/draft-ietf-eppext-keyrelay/
>> 
>> IESG discussion can be tracked via
>> https://datatracker.ietf.org/doc/draft-ietf-eppext-keyrelay/ballot/
>> 
>> 
>> The following IPR Declarations may be related to this I-D:
>> 
>>  https://datatracker.ietf.org/ipr/2393/
>> 
>> 
>> 
>> _______________________________________________
>> EppExt mailing list
>> EppExt@ietf.org
>> https://www.ietf.org/mailman/listinfo/eppext
> 
> 
> 
> 
> _______________________________________________
> EppExt mailing list
> EppExt@ietf.org
> https://www.ietf.org/mailman/listinfo/eppext
> 
> 