Hi, > On Nov 16, 2016, at 4:02 PM, Ulrich Wisser <ulr...@wisser.se> wrote: > > Hi! > > Yesterday at the DNSOP meeting some IPR issues came up. > At that meeting the AD and IAB told us explicitly that we can not discuss the > IPR. > Today I had a short talk with Andrew Sullivan about the IPR and he confirmed > that we are not supposed to discuss the IPR. The IPR is only meant to > allow us to make an informed decision. > The IPR was filed long before we went to LC. It was mentioned on the list > and in f2f meetings. So we can believe that the wg participants knew about > the > IPR when they agreed that the document is ready for publication. > > What more should the wg have done?
The typical procedure is that when the IPR disclosure is filed, the WG chairs ask the WG whether they want to continue progressing the document in light of the disclosure. That has now happened and there has been a bunch of feedback so I would expect this to be resolved shortly. Alissa > > /Ulrich > > Stephen Farrell <stephen.farr...@cs.tcd.ie > <mailto:stephen.farr...@cs.tcd.ie>> schrieb am Do., 10. Nov. 2016 um 20:17 > Uhr: > Stephen Farrell has entered the following ballot position for > draft-ietf-eppext-keyrelay-12: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > <https://www.ietf.org/iesg/statement/discuss-criteria.html> > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-eppext-keyrelay/ > <https://datatracker.ietf.org/doc/draft-ietf-eppext-keyrelay/> > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > > (1) The IPR declaration says that license terms will be available > "later." As things stand, I don't understand how the WG can have > made an informed decision in that case. I looked at the archive > and saw essentially no discussion, other than the announcement. I > also looked at the application and it's not crystal clear to me at > least that none of the claims are relevant. The shepherd write-up > also doesn't help me, but of course there may have been discussion > in a f2f meeting that is documented in minutes or something - I've > not checked for such, or I may have missed out on some list > traffic. Anyway, the DISCUSS is to ask did I miss stuff and if not > how can WG participants have rationally considered an IPR > declaration if the licensing information will only arrive "later" > after the document is approved to become an RFC? (Note: If I am > explicitly told that this was considered and participants were ok > with the declaration even as-is, then I'll clear.) > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > > OLD COMMENTS and cleared-DISCUSS point below. (There's > no need to read beyond here:-) > > (2) So I can see at least two ways in which this kind of thing can > be done and you don't clearly say which this supports. Option (a) > would be for the gaining DNS operator to provide new public keys > to the losing operator for inclusion before a transfer so that > continuity is maintained during the transfer. Option (b) would be > where the KSK private material is not known by either > operator, but e.g. by the registrant. In the case of option (b) > the DNSKEY would be transferred from the losing to the gaining DNS > operator. (And the arrow in Figure 1 would be in the other > direction.) I think you need to be clear about which of these > cases is actually being supported and about the overall sequence > of events needed. (If you tell me that you really want to do > whatever is in draft-koch, then that's fine but then this draft is > probably premature and draft-koch would need to be a normative > ref.) > > - I think I'm missing an overview of EPP here. The intro could > maybe do with a short para, and/or a pointer to something general. > (Ah, I get it in section 3 - the ref to 5730 might be better in > the intro.) > > - general: I think it'd be better to talk about public key values > and not "key material" as the latter is often used to describe > secret/private values which aren't at issue here. (Or else > I'm mis-reading stuff:-) > > - nit, p8: s/previously send/previously sent/ > > - Section 6: I'm surprised that you don't recommend or even note > that the gaining registrar/dns operator should be able to check > that the DNSKEY value it sees in XML is or is not the same as one > that is published in the DNS and verifiable there. Wouldn't that > kind of cross check be useful? > > > -- > Ulrich Wisser > ulr...@wisser.se <mailto:ulr...@wisser.se>
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
