Subject: [eppext] Working Group Last Call for draft-ietf-eppext-keyrelay

From: James Galvin <[email-masked]>
Date: Thu, 23 Jul 2015 16:04:55 +0200

This is the start of the WGLC for "Key Relay Mapping for the Extensible 
Provisioning Protocol".

My co-chair Antoin is one of the authors of this document, he has 
recused himself from managing the progression of this document through 
the IETF process.

There has been extensive discussion on the mailing list, I believe all 
issues and concerns have been resolved, and the document is ready for WGLC.

The current version of this document can be found here:

     https://datatracker.ietf.org/doc/draft-ietf-eppext-keyrelay-04/

We will have 1 week last call period closing in Friday, 31 July 2015.

The document shepherd for this document will be Ulrich Wisser.

Jim

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Thu, 23 Jul 2015 14:25:50 +0000

> -----Original Message-----
> From: EppExt [mailto:[email-masked]] On Behalf Of James Galvin
> Sent: Thursday, July 23, 2015 10:05 AM
> To: eppext
> Subject: [eppext] Working Group Last Call for draft-ietf-eppext-
> keyrelay
> 

I have reviewed this document. Mostly minor comments except for the last one:

1. the URL above 404s for me. This one worked:

https://datatracker.ietf.org/doc/draft-ietf-eppext-keyrelay/

2. I'd recommend removing the reference from the abstract. Abstracts should be able to stand alone outside the document without references.

OLD:
[RFC5730]

NEW:
RFC 5730

3. Section 1.2: "focuses" is misspelled as "focusses".

4. Section 5: A template should be included to register the XML schema described in Section 4. Suggestion: Replace the existing Section 5.2 with this template, and bump 5.2 to 5.3.

Registration request for the key relay XML schema:

  URI: urn:ietf:params:xml:schema:keyrelay-1.0

  XML: See Section 4 ("Formal Syntax") of this document.

It appears that this IANA registry (http://www.iana.org/assignments/xml-registry/xml-registry.xhtml#schema) does not require a registrant contact.

Scott

---

From: Antoin Verschuren <[email-masked]>
Date: Thu, 23 Jul 2015 17:00:58 +0200

I have a minor comment I already notified the authors directly.

In the definition of the expiry element, it suggests a negative relative expiry or a date in the past for an absolute expiry in case a relayed key needs to be revoked.
Since I think it’s impossible for the receiving dns-operator to revoke a key in the past, an absolute expiry of the current date and a relative expiry of zero are better values to be interpreted to revoke an already relayed key immediately.

This may show up in a next version of the draft, so everyone knows where this change originates from.

There is an informative reference in the document to draft-koch-dnsop-dnssec-operator-change that has expired.
Unlike a normative reference, the AD has informed us that this is not an issue.
I’d like to inform you though, that since we seem to have consensus and implementation intentions on this draft, the authors of draft-koch-dnsop-dnssec-operator-change intend to revive that document so it may become an informational RFC.

- --
Antoin Verschuren

Tweevoren 6, 5672 SB Nuenen, NL
M: +31 6 37682392
xmpp:[email-masked]

Op 23 jul. 2015, om 16:04 heeft James Galvin <[email-masked]> het volgende geschreven:

> This is the start of the WGLC for "Key Relay Mapping for the Extensible Provisioning Protocol".
> 
> My co-chair Antoin is one of the authors of this document, he has recused himself from managing the progression of this document through the IETF process.
> 
> There has been extensive discussion on the mailing list, I believe all issues and concerns have been resolved, and the document is ready for WGLC.
> 
> _______________________________________________
> EppExt mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/eppext

---

From: Rik Ribbers <[email-masked]>
Date: Thu, 23 Jul 2015 15:54:34 +0000

Scott,

Thanks for the feedback, Point 1 I will leave for the chairs.  Point 2, 3 and 4 are done in the working copy so they will appear in the next version.

Regarding point 4 : 
During the break you mentioned that we need to register a namespace and a schema in the IANA XML registry that clarified it. I have added an extra paragraph for the schema registration.

Gr,
Rik 

-----Original Message-----
From: EppExt [mailto:[email-masked]] On Behalf Of Hollenbeck, Scott
Sent: donderdag 23 juli 2015 16:26
To: James Galvin; eppext
Subject: Re: [eppext] Working Group Last Call for draft-ietf-eppext-keyrelay

OLD:
[RFC5730]

NEW:
RFC 5730

Scott

---

From: Rik Ribbers <[email-masked]>
Date: Thu, 23 Jul 2015 16:11:42 +0000

This has also been incorporated in the working copy of the draft and will appear in the next version (targeted right after the end of WG last call next Friday).

Gr,
Rik 

-----Original Message-----
From: EppExt [mailto:[email-masked]] On Behalf Of Antoin Verschuren
Sent: donderdag 23 juli 2015 17:01
To: [email-masked]
Subject: Re: [eppext] Working Group Last Call for draft-ietf-eppext-keyrelay

In the definition of the expiry element, it suggests a negative relative expiry or a date in the past for an absolute expiry in case a relayed key needs to be revoked.
Since I think it's impossible for the receiving dns-operator to revoke a key in the past, an absolute expiry of the current date and a relative expiry of zero are better values to be interpreted to revoke an already relayed key immediately.

There is an informative reference in the document to draft-koch-dnsop-dnssec-operator-change that has expired.
Unlike a normative reference, the AD has informed us that this is not an issue.
I'd like to inform you though, that since we seem to have consensus and implementation intentions on this draft, the authors of draft-koch-dnsop-dnssec-operator-change intend to revive that document so it may become an informational RFC.

- --
Antoin Verschuren