[regext] Call for agenda items for Berlin
Dear WG, Jim and I have requested a 2 hour meeting slot for the IETF96 meeting in Berlin. This is a call for agenda items for our upcoming meeting. Jim and I have some ideas what we want to talk about, and we have quite some new adopted documents due to our rechartering last meeting, but we would like to give you the opportunity to fill the agenda first. The agenda is still pretty blank for now, but we would like to urge the authors of the latest adopted documents to give a status update and discuss choices and changes. Please send your items to the chairs or the list as soon as you can, Regards, - -- Antoin Verschuren Tweevoren 6, 5672 SB Nuenen, NL M: +31 6 37682392 signature.asc Description: Message signed with OpenPGP using GPGMail ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
[regext] Meeting in Chicago
Dear working group, It’s time again to start scheduling for our next meeting. The chairs need to make a meeting request before this friday. We intend to meet in Chicago, but following up on our discussion in Seoul, we have an important question for you: Do you want one traditional meeting slot only discussing progress, or do you want two 1 hour slots with one slot reserved as a working session on doing actual work on documents? Please let us know before friday. And as always, this is also a request for agenda items to see how much time we need for our regular session. Regards, Jim and Antoin - -- Antoin Verschuren Tweevoren 6, 5672 SB Nuenen, NL M: +31 6 37682392 signature.asc Description: Message signed with OpenPGP using GPGMail ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] Interest in Drafts?
Dear working group, Scott has sent this question to the mailinglist almost a month ago, and so far there has not been one reaction. The chairs believe that the RDAP drafts Scott suggested fall within the charter of this working group, as RDAP extensions are part of our charter. But we do need sufficient participation for review for us to take documents onboard. That’s not only true for these documents, but for all documents already in our charter. When we rechartered, we had sufficient voiced support for review of documents, but it seems not all subjects share the same interest over time. No interest in a specific solution also needs advise on why it’s not needed or a bad idea. So I have a number of questions for you: 1. Do we have any volunteers to review these RDAP documents? For us to do a good job in progressing existing and adopting new documents, we need reviewers and expert advise. We realize that this is a small working group and most of us only concentrate on issues at hand we encounter ourselves. For us to take on RDAP documents since we rechartered, I have the following questions: 2. Could we identify the organizations that have or are implementing RDAP so we can motivate them in participating if they don’t already? 3. Could we make a list of implementations, published/intended policy proposals and RDAP toolkits? 3. If you are aware of RDAP implementers or policy reviewers not aware of this working group, could you please motivate them in participating? It’s needles to say that by the time your organization needs to implement the products of this working group, the time to complain about improper design has passed, and we hope you can convince your staff and management that the time to invest in proper design is now, before you start implementing at scale. If we fail do do proper review within this working group, the risk is that the early adopters will make individual submissions for the protocol adjustments they need without consulting the needs of others in this field for the future, and would give us much more work afterwards to restore, or even failure of or criticism on our industry diversity. Regards, - -- Antoin Verschuren Tweevoren 6, 5672 SB Nuenen, NL M: +31 6 37682392 Op 12 jan. 2017, om 19:36 heeft Hollenbeck, Scott <shollenb...@verisign.com> het volgende geschreven: > Is anyone interested in reviewing a pair of drafts that I shared on-list a > few weeks ago? Both address gaps in RDAP functionality and could actually be > useful in production environments: > > https://datatracker.ietf.org/doc/draft-fregly-regext-rdap-search-regex/ > > https://datatracker.ietf.org/doc/draft-hollenbeck-regext-rdap-object-tag/ > > My team has working prototypes up and running and we are very interested in > your feedback. If there's interest we'd like to ask the WG to consider them > for adoption. > > Scott > > ___ > regext mailing list > regext@ietf.org > https://www.ietf.org/mailman/listinfo/regext signature.asc Description: Message signed with OpenPGP using GPGMail ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] I-D Action: draft-ietf-regext-reseller-ext-01.txt
ing list to get a clearer consensus or discussion? Do the authors want to do this themselves, or do they need any help from the chairs? regards, - -- Antoin Verschuren Tweevoren 6, 5672 SB Nuenen, NL M: +31 6 37682392 signature.asc Description: Message signed with OpenPGP using GPGMail ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
[regext] Meeting in Seoul
Dear WG, It’s this time again that we need to start thinking of our next meeting in Seoul. Jim and I have looked over our chartered milestones, and Jim is going to reach out to authors of documents that did not seem to have made progress to ask for a status update. In the mean time, we need to schedule for Seoul. Looking at the list of documents and progress, we intend to ask for a 90 minute time slot in Seoul. To get a sense if that’s enough, we ask you if there is anything special you would like to discuss in Seoul, including the chartered documents or documents to be adopted. Apart from status updates, there’s encouragement within the IETF to devote part of our time to unstructured collaboration, to see if that can progress our work faster. We may put up an agenda item to discuss that in Seoul, but if you already have some ideas we would like to hear from you. Think of things like a demo, hacking session, compliance testing, or a reviewers meeting request you would like to clarify during the meeting. Please let us know before Friday, as that is our deadline for meeting sessions requests. regards, Jim and Antoin - -- Antoin Verschuren Tweevoren 6, 5672 SB Nuenen, NL M: +31 6 37682392 signature.asc Description: Message signed with OpenPGP using GPGMail ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] draft-ietf-eppext-keyrelay unreasonably stuck on IPR?
[Personal statement: Chair hat off]
Just so that everyone has the same information regarding the IPR we are
discussing, the patent application and it’s EPO process can be found here:
https://register.epo.org/ipfwretrieve?apn=US.201113078643.A=en
The patent application has been officially rejected by the patent office twice
now in the past 5 years due to prior art.
This is without me as the original inventor of the secure dns-operator change
method submitting any personal prior art that stems back to 2008 when I first
thought of the idea during a DNSSEC workshop for operations staff while working
for SIDN.
I have discussed this method in an IETF, DNS-OARC, CENTR and ICANN context with
fellow IETFers including Verisign staff, and gave presentations about it, which
led to the prior art before the first version of
draft-koch-dnsop-dnssec-operator-change was published by the IETF in March 2011
and the Verisign patent application a month later.
This and the fact that I’m a co-author of both draft-ietf-eppext-keyrelay and
draft-koch-dnsop-dnssec-operator-change is why my co-chair Jim is leading the
process on draft-ietf-eppext-keyrelay and I attempt to state no personal
opinions in this process or judgement of the opinions of others in this process.
[/Chair hat off]
Like most of you, I am no patent expert or lawyer.
Verisign is following the IETF IPR process as defined by the IETF, and it has
every right to do so.
So please don’t blame Verisign or Scott personally.
The Patent office procedures are what they are, and we cannot change them or
speed them up either.
Verisign can do the latter, but is not obliged to do so by any IETF rule, only
by willingness.
That being said, we as a working group need to decide what we want to do.
I agree with Job that it is unfortunate that the IETF IPR process allows a
pending patent application that has no licensing terms yet to stall the IETF
process.
If this needs to change, I think we need to discuss this in a broader IETF
context, but I think it will be very hard, if it is even possible legally to
mandate licensing terms on IPR statements submitted to the IETF.
If we think Verisign has breached the IETF Note Well by patenting solutions
after they were discussed during IETF meetings, that discussion also needs a
broader IETF context than this working group. This will also mean a long legal
battle which few individual IETF participants would be able to afford, and
would require broader IETF consulting and guidance from the IESG.
So as a working group, we basically have only 2 options left:
1. We could kindly convince Verisign with arguments that stallment of this IPR
claim is negatively impacting Internet security like Job has done, and ask them
to withdraw or quickly proceed with their application. In this case, if
Verisign is not willing to state licensing terms beforehand, we are still
dependent on the Patent office procedures and timelines, and we will just have
to wait for that.
2. We could jointly state that we took notice of the IPR claim, and that no
matter what the licensing terms or outcome of the application is, we would like
to standardize the solution in our Internet draft since it is the only best
solution.
I would be hesitant to choose for option 2 on the argument that many believe
the application will be rejected by the patent office in the end as there is
sufficient prior art, since I am not a Lawyer, nor do I have the funds to pay
for one in the small chance the patent office will make the wrong decision in
approving the application to get it off their plate.
If we choose for option 2, we need to state why we think the patent application
or it’s licensing terms don’t matter to us.
Jim has asked for this before, with little to no response to call consensus to
have this draft proceed, so I would like to ask you again to state your opinion
on this mailinglist so Jim can summarize them in a response to the IESG.
- --
Antoin Verschuren
Tweevoren 6, 5672 SB Nuenen, NL
M: +31 6 37682392
Op 9 nov. 2016, om 14:41 heeft Job Snijders <j...@instituut.net> het volgende
geschreven:
> On Wed, Nov 09, 2016 at 12:19:44PM +, Hollenbeck, Scott wrote:
>>> Because Verisign still has the option to provide a more detailed
>>> Licensing Declaration ahead of the issuance, covering whatever claims
>>> (if any) will be allowed.
>>>
>>> Why has Versign choosen not to provide a Licensing Declaration such as
>>> option A ('no license'), B ('Free RAND'), C ('RAND') or E ('NOPE')?
>>>
>>> In failing to provide clarity to the internet engineering community,
>>> Verisign is arguably obstructing much needed internet security
>>> mechanisms.
>>
>> In my last note I explained why the decision was made to not update
>> the disclosure: we do not know if the patent will be granted, and we
>> do not know which
[regext] Agenda items for IETF97
Hi all, It’s time to start preparing for Seoul. This is a call for agenda items. We requested a 1,5 hour slot, but so far we received a 2 hour slot on Friday, so we have enough time left. I posted a preliminary agenda below. Authors that see their documents on the agenda and want to present updates or discussions, please do! and let us know. Registration Protocols Extensions (REGEXT) IETF 97, Seoul, South Korea, Agenda Co-chairs: Jim Galvin, Antoin Verschuren Mailinglist: regext@ietf.org 1. Welcome and Introductions (5 minutes) i. Jabber scribe ii. Notes scribe iii. NOTE WELL 2. Existing Document Status 2.a. En route to publication (IESG review) (10 minutes) i. https://datatracker.ietf.org/doc/draft-ietf-eppext-keyrelay/ IPR claim discussion on the mailinglist. Please submit your views. ii. https://datatracker.ietf.org/doc/draft-ietf-regext-epp-rdap-status-mapping/ EPP "stateâ vs "business rulesâ discussion on mailinglist regarding RFC3915 2b. Working group last call documents (15 minutes) i. https://datatracker.ietf.org/doc/draft-ietf-regext-launchphase/ ii. https://datatracker.ietf.org/doc/draft-ietf-regext-tmch-func-spec/ Issues with normative references related to ICANN documents. Last proposal: Move the claims phase definition to the launchphase document so the launchphase document can proceed as standards track, and make the tmch-func-spec document informational to describe the ICANN process. 2.c. REGEXT Working group documents (30 minutes) i. https://datatracker.ietf.org/doc/draft-ietf-regext-bundling-registration/ On hold pending status DNSBUNDLED BOF. Update on DNSBUNDLED BOF. iv. https://datatracker.ietf.org/doc/draft-ietf-regext-reseller/ https://datatracker.ietf.org/doc/draft-ietf-regext-reseller-ext/ Update presentation (Linlin Zhou, 10 minutes) Important open question: What are we trying to solve here? Single RDAP requirement use case versus new role definition. v.https://datatracker.ietf.org/doc/draft-ietf-regext-epp-fees/ Renamed, but waiting for updates. vi. Any other activity (Adoption requests, Renaming, Milestones) Next on our list of milestones, so renaming requests sent to: https://datatracker.ietf.org/doc/draft-gould-allocation-token/ https://datatracker.ietf.org/doc/draft-gould-change-poll/ https://datatracker.ietf.org/doc/draft-gould-eppext-verificationcode/ https://datatracker.ietf.org/doc/draft-xie-eppext-nv-mapping/ 3. Discussion: Spending Working group meeting time on live issue solving. (20 min.) The IETF encourages working groups to think about or experiment with unstructured meeting time in one of their slots. This time could be used for free-form discussion in the whole group, an âunconference" style idea session in the different corners of the room, or a hacking session devoted to the WG's technology for example. The REGEXT chairs are open for ideas of using unstructured meeting time if that will help our work proceed faster. We have a small working group with limited resources, that seem to be more productive around meetings. One of the suggestions could be that we would have live document text editing or issue list brainstorming time reserved on our agenda. A negative consequence could be that remote participation for such time would be harder, or that not everything is publicly recorded. We would like to hear your opinion. This 20 minutes, we are open to suggestions and ideas. 4. AOB Jim and Antoin - -- Antoin Verschuren Tweevoren 6, 5672 SB Nuenen, NL M: +31 6 37682392 signature.asc Description: Message signed with OpenPGP using GPGMail ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] I-D Action: draft-ietf-regext-reseller-ext-01.txt
a "Reseller ID”. The syntax of its corresponding element is defined in this document/[ID.draft-ietf-regext-reseller]." And then add the syntax definition in [ID.draft-ietf-regext-reseller], and words on who assigns the ID according to what rules (first-come-first-serve/registry defined/registrarid preceded?) I leave the rest of my questions and remarks till we have a suggestion for the reseller object, as I think that may change the current text quite a bit.. Regards, - -- Antoin Verschuren Tweevoren 6, 5672 SB Nuenen, NL M: +31 6 37682392 Op 7 dec. 2016, om 09:35 heeft Linlin Zhou <zhoulin...@cnnic.cn> het volgende geschreven: > This is a very minor update, mostly just to keep the document alive to > discuss on path of reseller object or entity object with multiple roles. > > Regards, > Linlin Zhou > > From: internet-drafts > Date: 2016-12-07 16:30 > To: i-d-annou...@ietf.org > CC: regext > Subject: [regext] I-D Action: draft-ietf-regext-reseller-ext-01.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Registration Protocols Extensions of the > IETF. > > Title : Reseller Extension for the Extensible Provisioning > Protocol (EPP) > Authors : Linlin Zhou > Ning Kong > Junkai Wei > Xiaodong Lee > James Gould > Filename: draft-ietf-regext-reseller-ext-01.txt > Pages : 18 > Date: 2016-12-07 > > Abstract: >This mapping, an extension to EPP object mappings like the EPP domain >name mapping [RFC5731], to support assigning a reseller to any >existing object (domain, host, contact) as well as any future >objects. Specified in Extensible Markup Language (XML), this >extended mapping is applied to provide additional features required >for the provisioning of resellers. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-regext-reseller-ext/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-regext-reseller-ext-01 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-regext-reseller-ext-01 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > ___ > regext mailing list > regext@ietf.org > https://www.ietf.org/mailman/listinfo/regext > ___ > regext mailing list > regext@ietf.org > https://www.ietf.org/mailman/listinfo/regext signature.asc Description: Message signed with OpenPGP using GPGMail ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] Working group action required on draft-ietf-regext-reseller-ext-01.txt
Hi James, I understand your distinction between registrar and reseller, and I agree. Registrars are provisioned differently, and have a formal role to provisioning objects and contracts, just as registrants do. I didn’t suggest to have registrars/registrants be transformed into generic organizations objects just yet if that was what you were thinking I meant. It’s other future roles that I see similar to resellers why I would want a generic organizational object to be used for resellers. If the name "generic organization” confuses you, we might also call it "additional registration liaisons” or whatever is appropriate, but it’s more than just resellers. So in fact we would have 3 "objects" for entities/organizations: 1. Registrants (mandatory in any registration contract, even in a situation without registrars or resellers, yes, direct registrations still exist at some registries!) 2. Registrars (if present, usually authoritative for the provisioning data, and often also for billing information in the ICANN model at least) 3. All other organizations not formally defined by or mandatory in registration contracts. The pragmatic problem being considered now is indeed making non contractual resellers visible, but I expect other organizations -not resellers- on the horizon with the same wish to be tagged to provisioning objects as well. They might need to be visible as well, or even have special permissions, and they might have multiple roles. Roles I expect include dns-operators, auditors, expanded RDAP access credentials, abuse desks, law enforcement, privacy agents, data processors etc.. I wouldn’t want to define a new object every time I wanted to innovate service to customers. I just want to give the object an additional role in relation to a provisioning object, so they can use the new service belonging with that role. - -- Antoin Verschuren Tweevoren 6, 5672 SB Nuenen, NL M: +31 6 37682392 Op 3 mrt. 2017, om 16:12 heeft Gould, James <jgo...@verisign.com> het volgende geschreven: > I believe that “Option 1: A dedicated reseller object” is the best route to > go. I get the idea of creating a generic organization, but you need to > consider the problem being considered and the difference of a registrar from > a reseller. > > 1. A registrar (direct customer) has a direct relationship with the > registry and is provisioned outside of EPP or any B2B protocol. A registrar > organization would only support an info unless you enable a registrar to > update their own record via EPP, which seems like a real stretch use case. > 2. A registrar is automatically attached to the provisioned objects > (e.g., domain, host, and contact) in the registry based on the create and > transfer commands. There is need for tagging a provisioning object with a > direct customer organization. > > The problem that is being considered is making the resellers visible at the > registry level to support tagging of provisioning objects for display in > RDDS, for applying registrar controlled reseller policy (security, financial, > etc.) at the registry level, and providing registry provided reports and > visualizations split out by reseller. > > Is there another problem that needs to be solved by elevating the reseller > object up to the more generic organization? > > > — > > JG > > > > James Gould > Distinguished Engineer > jgo...@verisign.com > > 703-948-3271 > 12061 Bluemont Way > Reston, VA 20190 > > VerisignInc.com > > From: regext <regext-boun...@ietf.org> on behalf of "Hollenbeck, Scott" > <shollenb...@verisign.com> > Date: Friday, March 3, 2017 at 9:22 AM > To: "'i...@antoin.nl'" <i...@antoin.nl>, "'regext@ietf.org'" <regext@ietf.org> > Subject: [EXTERNAL] Re: [regext] Working group action required on > draft-ietf-regext-reseller-ext-01.txt > > From: regext [mailto:regext-boun...@ietf.org] On Behalf Of Antoin Verschuren > Sent: Friday, March 03, 2017 8:54 AM > To: regext <regext@ietf.org> > Subject: [EXTERNAL] Re: [regext] Working group action required on > draft-ietf-regext-reseller-ext-01.txt > > No expressions of preference have been expressed for over a month now :-( > I think the authors deserve good guidance from the working group so they can > progress their drafts, so let me be the first to express my motivation. > I hope we can discuss this in Chicago, so more opinions are certainly needed > on the mailinglist! > > [chair hat off, personal opinion] > > I have a strong preference for option 2, a generic organization object, and a > reseller mapping to such an organization object to identify resellers for a > domain. > > [snip] > > Same here, though I do
Re: [regext] Working Session @ IETF 98
Op 3 mrt. 2017, om 14:36 heeft Gould, James <jgo...@verisign.com> het volgende geschreven: > Antoin, > > I’m willing to help facilitate or participate in the reseller drafts > (draft-ietf-regext-reseller and draft-ietf-regext-reseller-ext) sub-group; > although the draft-ietf-regext-epp-fees sub-group is a high priority for me. > You may be able to split it based on EPP based sub-groups and RDAP based > sub-groups. Hi James, We like this idea of splitting up in a parallel RDAP and EPP track, and then handle documents in serial. I have put you on the draft agenda for the reseller discussion that will be published later today. I’m happy to clarify my personal thoughts on these documents and take part in the discussion remotely. We will have one meetecho setup in the room, and Jim and I will schedule the work session as to accommodate the remote participation for this discussion. - -- Antoin Verschuren Tweevoren 6, 5672 SB Nuenen, NL M: +31 6 37682392 signature.asc Description: Message signed with OpenPGP using GPGMail ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
[regext] Preliminary Agenda for IETF 98
Hi all, I have uploaded our preliminary agenda's for Chicago. The agenda for both sessions can be found here: https://www.ietf.org/proceedings/98/agenda/agenda-98-regext-06 I have put placeholders in the work session part of the agenda for the facilitators to list issues that they wish to discuss. Please contact the chairs with issues you want people to prepare for this session to be listed in the agenda. If there are any additional requests, please let the chairs know. We have received a generous 2 hour slot for our working group session where we requested 1 hour, so we will have enough time. Regards, Antoin and Jim - -- Antoin Verschuren Tweevoren 6, 5672 SB Nuenen, NL M: +31 6 37682392 signature.asc Description: Message signed with OpenPGP using GPGMail ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
[regext] Call for agenda items/preliminary agenda IETF 98
Hi All, This is a call for agenda items for our regular working group session at IETF 98 in Chicago. Please find our preliminary agenda below. As you may see, our agenda is already quite full for the one hour we have for this session, so we may need to ask specific document discussions (like items i. and ii. in 2.c.) to move to our working sessions earlier in the week. It would be good to have expressions of interest in these discussions to move them around. If you have any additional agenda items, please let us know. Antoin and Jim. Registration Protocols Extensions (REGEXT) IETF 98, Chicago, USA, Agenda Co-chairs: Jim Galvin, Antoin Verschuren Mailinglist: regext@ietf.org 1. Welcome and Introductions (5 minutes) i. Jabber scribe ii. Notes scribe iii. NOTE WELL 2. Existing Document Status 2.a. Published (2 minutes) i. Extensible Provisioning Protocol (EPP) and Registration Data Access Protocol (RDAP) Status Mapping RFC 8056 (Was draft-ietf-regext-epp-rdap-status-mapping) ii. Key Relay Mapping for the Extensible Provisioning Protocol RFC 8063 (was draft-ietf-eppext-keyrelay) 2.b. Working group last call documents (5 minutes) i. https://datatracker.ietf.org/doc/draft-ietf-regext-launchphase/ Is it ready for WG last call now? 2.c. REGEXT Working group documents (20 minutes) i.https://datatracker.ietf.org/doc/draft-ietf-regext-reseller/ https://datatracker.ietf.org/doc/draft-ietf-regext-reseller-ext/ No follow up response on mailinglist :-( ii. https://datatracker.ietf.org/doc/draft-ietf-regext-dnsoperator-to-rrr-protocol/ Jaques Latour (10 min?) iii. Any other activity (Adoption requests, Renaming, Milestones) Let’s take a good look at the documents on our milestone list, adoption requests, and reorder. 3. Working session summary (15 minutes) i.https://datatracker.ietf.org/doc/draft-hollenbeck-regext-rdap-openid/ https://datatracker.ietf.org/doc/draft-hollenbeck-regext-rdap-object-tag/ https://datatracker.ietf.org/doc/draft-fregly-regext-rdap-search-regex/ Scott Hollenbeck (10 minutes) ii. https://datatracker.ietf.org/doc/draft-ietf-regext-epp-fees/ Roger Carney (5 minutes) 4. Contact postal info elements discussion (James Gould, 10 minutes) https://mailarchive.ietf.org/arch/msg/regext/NGD6WvTFZgh_mY3twoFH2A-M5Ds 5. AOB - -- Antoin Verschuren Tweevoren 6, 5672 SB Nuenen, NL M: +31 6 37682392 signature.asc Description: Message signed with OpenPGP using GPGMail ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] Working group action required on draft-ietf-regext-reseller-ext-01.txt
No expressions of preference have been expressed for over a month now :-( I think the authors deserve good guidance from the working group so they can progress their drafts, so let me be the first to express my motivation. I hope we can discuss this in Chicago, so more opinions are certainly needed on the mailinglist! [chair hat off, personal opinion] I have a strong preference for option 2, a generic organization object, and a reseller mapping to such an organization object to identify resellers for a domain. Motivation: 1. Reusable. An organization object could be reusable for future entities like dns-operators, RDAP authorization, reporting entities etc. We only need to define a new mapping for a new role, and not need a new object and attribute definitions. 2. Mandatory attributes are local policy. So far the discussion was on which attributes should be mandatory for a reseller. I believe this is local policy, and doesn’t belong in the protocol definition. As I see it, only an organization’s name and ID could be mandatory attributes, and all other attributes should be optional protocol wise. We can define as many optional attributes we can think of, and off course the protocol is still extensible after that, but at least we will have a uniform definition for the most common ones. The fact that the attributes are defined does not mean they need to be filled in!! It is up to local policy to decide which of these aditional organizational attributes are mandatory to be mapped a certain role. This will facilitate the basic requirements we have now for displaying minimal reseller information in RDAP, but will allow organizations to voluntarily supply extra information if necessary, and for registries to have their own local policy in agreement with their local registrar and reseller community. The protocol should be wider applicable than just ICANN registrars. I will strongly object to additional mandatory attributes where that should be defined in local policy by the registry in question. 3. Innovation. Defining a more reusable organization object now will allow for easy innovation later without having to go through the trouble of adapting the protocol. As an example: If I want to create a process to allow a DNS-operator to adjust NS records with the consent of the registrar of record, I would only need to make sure that the organization object has verified credential attributes filled in, and registrar permission. I wouldn’t need to extend the protocol to define these attributes, potentially differing from other registries extensions for the same purpose. 4. Multiple roles. Using a more generic "organization” object, not tagging an organization as a one and only role as a reseller will allow an entity to have multiple roles. This will decrease data to be maintained by both registry and the organizations involved. - -- Antoin Verschuren Tweevoren 6, 5672 SB Nuenen, NL M: +31 6 37682392 Op 9 feb. 2017, om 02:31 heeft Linlin Zhou <zhoulin...@cnnic.cn> het volgende geschreven: > Thanks for chair's support. We really need more options from WG to decide the > drafts' direction. > From the perspective of authors, we still think a reseller object is a more > preferable way to fullfil the current requirements. But a more generic object > is an optional choice for us to consider. And we need some discussion on the > generic attributes for the new object. > Any comments or opinions are warmly welcome. > > Regards, > Linlin Zhou > > From: Antoin Verschuren > Date: 2017-02-07 18:18 > To: regext > Subject: [regext] Working group action required on > draft-ietf-regext-reseller-ext-01.txt > Dear working group, > > This is a request for action for you! Yes you! Reader of this mail, > participant in this working group, or provisioning expert you forward this > mail to. > > Resulting from our last session in Seoul and follow up discussion on the > mailinglist a few weeks ago, we still need to make a clear decision on advise > for the authors of the reseller drafts in which direction the working group > wants these documents to progress. So far, there has not been an overwhelming > feedback. We realize that not every draft may attract your attention, but for > this working group to produce any quality documents, it’s vital that drafts > are reviewed and multiple angle advise is given. > > This is a request to please take some time to review the purpose of the > reseller drafts. > Detailed XML review is welcomed, but to answer this one question that the > authors are desperately waiting on, quantity of opinions and a good generic > overview of EPP and future registration processes is most important. > > To summarize where we left off in Seoul, and the question that we need an > anser
Re: [regext] Meeting Agenda for IETF-98?
Hi Scott, I’ll have a preliminary agenda and call for agenda items tomorrow, just waiting for some private responses about the working session. Stay tuned. - -- Antoin Verschuren Tweevoren 6, 5672 SB Nuenen, NL M: +31 6 37682392 Op 1 mrt. 2017, om 19:57 heeft Hollenbeck, Scott <shollenb...@verisign.com> het volgende geschreven: > Do we have any more info on the agenda for our working group meeting at > IETF-98? > > Scott > > ___ > regext mailing list > regext@ietf.org > https://www.ietf.org/mailman/listinfo/regext signature.asc Description: Message signed with OpenPGP using GPGMail ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] TLD Phase Discovery
Hi all, In order to achieve progress, I’m trying to summarize the discussion: 1. Most folks agree there may be a need for phase discovery. When there are multiple phases for registration, and there are real world examples for that, being able to discover the phase a domain is viable in through an availability check is at least "handy”, to avoid trial and error or out of bound discovery processes. This may be true for other EPP "knobs” as well though. 2. This need only arises in corner cases though. We’re not talking millions of domain names here. If we are, then there may be something wrong with the registry policy being too complex, and not the registration process. 3. The Launchphase draft and it’s check command was not meant to address this need. The launchphase process only describes how to do things once you know what you want to do. Can I conclude that the Launchphase draft should proceed as is? 4. The major demand for phase discovery is to discover the correct fee. I understand this business wise. You want to present your customer the correct fee during registration. But this one bugs me a little bit. While I understand that a special launch phase may be accompanied with a different fee because of potential special handling, this should not be a differentiator to group fees imho though. A (launch) phase is meant to differentiate in a different allocation policy, like preference or limitation in registrants, equal distribution, respect for trademarks or other policy related allocation. When trying to discover a phase based on it’s fee, it feels like you are trying to ignore the policy as the true differentiator, almost saying the policy doesn’t matter, and for the right fee, we will try to comply to or even ignore the policy in stead of the intent of first complying to the policy and then care for the extra fee. The question therefor is if the Fee document will be able to solve this? The major question for the chairs now is if we can proceed with the Launchphase document. The chairs believe that there is majority consensus to not change the Launchphase document. If not, we would like to hear that before the end of next week so we can proceed that document to the IESG. The second question then is if there is a need to change the Fee document to accommodate the use case Thomas needs. Or that it needs a more generic phase discovery like the suggestion for a Registry Mapping document. We expect that this will be discussed during the interim meeting next wednsesday. Please comment if any of my conclusions on the consensus is incorrect. Regards, - -- Antoin Verschuren Tweevoren 6, 5672 SB Nuenen, NL M: +31 6 37682392 Op 15 aug. 2017, om 15:42 heeft Gavin Brown <gavin.br...@centralnic.com> het volgende geschreven: > On 14/08/2017 19:27, Gould, James wrote: > >> As a co-author of Launch Phase Mapping going back 5 years and the one that >> added the “Domain names may be made available only in unique launch phases, >> whilst remaining unavailable for concurrent launch phases” language to the >> draft, I’m aware of the intent. Wil and Gavin can also weigh in on the >> intent. The intent was for the launch phases to be associated with the TLD >> (or zone), where there may be a policy for launch phases that differentiates >> the availability of domain names. It was never intended or foreseen that a >> launch phase would be used to group a set of domain names as a form of fee >> classification. We can agree to disagree on this topic. > > I agree with Jim. The Launch Phase was not designed to deal with premium > names: I would not have created the fee extension if it were. > > G. > > -- > Gavin Brown > Chief Technology Officer > CentralNic Group plc (LSE:CNIC) > Innovative, Reliable and Flexible Registry Services > for ccTLD, gTLD and private domain name registries > https://www.centralnic.com/ > > CentralNic Group plc is a company registered in England and Wales with > company number 8576358. Registered Offices: 35-39 Moorgate, London, > EC2R 6AR. > > ___ > regext mailing list > regext@ietf.org > https://www.ietf.org/mailman/listinfo/regext signature.asc Description: Message signed with OpenPGP using GPGMail ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] I-D Action: draft-hollenbeck-regext-rdap-object-tag-03.txt
Op 12 jun. 2017, om 13:03 heeft Hollenbeck, Scott <shollenb...@verisign.com> het volgende geschreven: > > Jim, given the just-announced updates, where does this document fit? Scott, Our AD first wants one item completed (the launchphase document sent to the IESG) before we add a new item to the milestones. So we will start the formal adoption request for this document on the mailinglist as soon as that’s done. Since the launchphase document shepherd finished his writeup today, there are only some nits left for the authors to fix, so I expect this to be this/next week. - -- Antoin Verschuren Tweevoren 6, 5672 SB Nuenen, NL M: +31 6 37682392 signature.asc Description: Message signed with OpenPGP using GPGMail ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] interim meetings proposal
Hi Roger,
Since we had no objections, I’m about to issue this interim meeting request.
2 small administration questions:
-How long will the meeting last (estimate, I have put 1 hour for now).
-Could you or expected attendees provide a bulleted list of issues you would
like to address or talk about?
("Discuss the most current revision of the Fee draft” for now, but that might
be hard to summarize :-))
And for the WG:
To give the chairs and organizer a sense of participation, since this will be
our first interim meeting, who on this mailinglist is thinking of joining this
session?
Regards,
- --
Antoin Verschuren
Tweevoren 6, 5672 SB Nuenen, NL
M: +31 6 37682392
Op 24 jun. 2017, om 18:05 heeft Roger D Carney <rcar...@godaddy.com> het
volgende geschreven:
> Good Afternoon,
>
> The latest revision, 05, of the fee draft was just posted.
>
> I would like to invite everyone to an interim meeting to discuss the most
> current revision of the Fee draft, draft-ietf-regext-epp-fees-05. This latest
> draft should account for all comments to this point.
>
> The meeting will be held Tuesday July 11th, 2017 at 13:00 UTC. We will
> utilize Zoom as the conferencing tool, please use this link to connect to the
> meeting.
>
>
> Thanks
> Roger
>
>
> -Original Message-
> From: James Galvin [mailto:gal...@elistx.com]
> Sent: Friday, June 23, 2017 8:19 AM
> To: Jody Kolker <jkol...@godaddy.com>
> Cc: Roger D Carney <rcar...@godaddy.com>; Registration Protocols Extensions
> <regext@ietf.org>
> Subject: Re: [regext] interim meetings proposal
>
> Yes, please, let’s move forward with scheduling a meeting to discuss the fee
> document on 11 July.
>
> Please take the lead.
>
> Jim
>
>
>
> On 21 Jun 2017, at 11:18, Jody Kolker wrote:
>
> > Thanks Jim/Antion/Adam,
> >
> > I fully support having virtual meetings between full IETF meetings. I
> > think it would help to move documents along faster. Roger and I were
> > discussing having a meeting for the fee document on July 11th. Will
> > we be able to have an approved meeting on that day?
> >
> >
> > Thanks,
> > Jody Kolker
> >
> >
> > -Original Message-
> > FromR: regext [mailto:regext-boun...@ietf.org] On Behalf Of James
> > Galvin
> > Sent: Friday, June 16, 2017 12:55 PM
> > To: Roger D Carney <rcar...@godaddy.com>
> > Cc: Registration Protocols Extensions <regext@ietf.org>
> > Subject: Re: [regext] interim meetings proposal
> >
> >
> >
> > On 16 Jun 2017, at 12:40, Roger D Carney wrote:
> >
> >> Good Afternoon,
> >>
> >>
> >>
> >> I think this is a great idea and I think this process looks
> >> acceptable. I have just one question and one comment.
> >
> > Thanks!
> >
> >
> >> Question: To clarify number 3 below "...chairs will handle
> >> administrative tasks...summary...", I assume the summary will be
> >> provided by the requester to the chairs for correct handling?
> >
> > Yes, that would be our preference. In fact, to go a step farther in
> > detail, if the interim meetings are “one document” meetings, then the
> > author/editor will prepare for the meeting with a bulleted list of
> > “issues” to discuss. The summary is most likely just the same
> > bulleted list with a few sentences or paragraphs (as needed) to state
> > the consensus of the meeting regarding the issue. This summary could
> > be posted to the list as is, as well as being used as the Secretariat
> > summary.
> >
> >
> >>
> >>
> >>
> >> Comment: As for "...as a replacement for the second WG meetings at
> >> IETF meetings...", I would like to see these interim meetings as an
> >> addition to and not a replacement. I think the F2F working sessions
> >> that we had at IETF-98 were very productive and we should try to keep
> >> doing.
> >
> > Thanks for this. We won’t have this option in Prague unfortunately
> > (the Chairs had timing conflicts this time) but I’m interested in
> > other points of view for the future.
> >
> > Jim
> >
> >
> >>
> >>
> >>
> >>
> >>
> >> Thanks
> >>
> >> Roger
> >>
> >>
> >>
> >>
> >>
> >> -Original Message-
> >> From: regext [mailto:regext-boun...@ietf.org] On Behalf Of James
> >> Galvin
> >> Sent: Friday, June 16, 2017 8:41 AM
> >> To: Registration Protocols Exten
Re: [regext] Proposed Changes to Milestones
Thank you for your support Roger, I answered your reseller drafts question in another message. We would like to get more support for our proposed changes. But as a matter of process, we intend to make these changes to the milestones beginning next week if there are no clear objections, so we can start planning for design team progress on our milestone drafts. If we cannot get enough consensus on the bundling and IDN drafts because there is no clear technical solution, demand or traction yet, a pragmatic proposal could also be to delete them from our milestones for now, and we can always add them again later. But at least we will know what we are working on now, and we could adopt new documents that do have traction. We’re interested on your thoughts. - -- Antoin Verschuren Tweevoren 6, 5672 SB Nuenen, NL M: +31 6 37682392 Op 19 mei 2017, om 17:01 heeft Roger D Carney <rcar...@godaddy.com> het volgende geschreven: > Good Morning, > > Thanks Jim/Antoin for working through all of these documents. > > I think these updates look good, except for a question on the reseller > documents. As I mentioned on list back in March, I thought in Seoul we > decided to review and comment but to not dedicate WG effort to these drafts? > > As far as the bundling and idn drafts, I have not followed these with too > much intensity so I will defer to others on these documents. > > > Thanks > Roger > > > -Original Message- > From: regext [mailto:regext-boun...@ietf.org] On Behalf Of James Galvin > Sent: Friday, May 19, 2017 8:41 AM > To: Registration Protocols Extensions <regext@ietf.org> > Subject: [regext] Proposed Changes to Milestones > > During the last IETF meeting we had a request to adopt another document. > As part of that discussion our AD expressed concern about the number of > documents currently on our list and the number of milestones currently on our > list. > > The Chairs took an action to review both of these and we now have a proposal > for consideration by the working group. > > To see the list of current milestones review this link: > > https://datatracker.ietf.org/group/regext/about/ > > To see the list of current documents review this link: > > https://datatracker.ietf.org/group/regext/documents/ > > The Chairs have contacted the authors of all documents and asked for their > feedback regarding the status of their document, reviewed the current > proposed milestone dates, and propose the following. These are shown as they > are listed in the current milestones. > > > > draft-ietf-regext-launchphase >WGLC finished. Waiting for shepherd write-up adjustments before submitting > to IESG. >Action: Change milestone date to June 2017. > > draft-ietf-regext-tmch-func-spec >Status changed to Informational. Changed to Parked document. >Action: Delete from milestone list. > > draft-ietf-regext-epp-rdap-status-mapping >RFC 8056 >Action: Set Status Resolved on milestone list. > > draft-ietf-regext-epp-fees >Recent version submitted. Active discussion. >Action: Change milestone date to July 2017. > > draft-ietf-regext-reseller > draft-ietf-regext-reseller-ext >These drafts have been replaced by draft-ietf-regext-org and > draft-ietf-regext-org-ext. >Active discussion. >Action: Accept new documents, replace on milestones, Change milestone date > to Nov 2017. > > draft-gould-eppext-verificationcode >No reaction from authors. >Action: Replace to draft-ietf-regext-verificationcode on milestone list >Change milestone date to June 2018. > > draft-xie-eppext-nv-mapping >(current milestone listing but document is really > draft-ietf-regext-nv-mappgin) >Informational document, waiting for > draft-ietf-regext-verificationcode >Action: Change to parked document. Delete from milestone list. > > draft-gould-change-poll (change to draft-ietf-regext-change-poll) >Needs more reviewers and implementation. >Action: Change milestone date to Nov 2017. > > draft-gould-allocation-token (change to > draft-ietf-regext-allocation-token) >Needs implementation status section and review. >Action: Change milestone date to Nov 2017. > > draft-ietf-regext-bundling-registration >New version submitted for STRICT bundling. > draft-ietf-eppext-idnmap > draft-gould-idn-table > draft-cira-regext-idn >These documents have discussion but no consensus. All these documents > relate. >Some want all IDN to be included in bundling discussion. >Action: Discuss. Chairs do not have a proposal for a milestone date of > these documents. We need input from the working group. > > dra
Re: [regext] I-D Action: draft-ietf-regext-dnsoperator-to-rrr-protocol-03.txt
Dear authors, I could finally find some time to make a more thorough personal (chair-hat off) preliminary review on this document. Here are my comments: First of all, I think everyone knows I’m a big fan of automating DNS provisioning processes and I would very much like this effort to succeed, so thank you to the authors for this attempt. However: Abstract: "When the domain uses DNSSEC it necessary to make regular” Nit: I think the word "is” is missing here? " This document describes a simple protocol that allows a third party DNS operator to update DS records for a delegation, in a trusted manner, without involving the Registrant for each operation. This same protocol can be used by Registrants.” This sounds dubious. Is the registrant involved or not? I would say: " This document describes a simple protocol that allows any DNS-operator to update DS records for a delegation, in a trusted manner, without involving any intermediate administratieve entities between the DNS-operator and the parent.” 1. Introduction: "After a domain has been registered, one of three parties will maintain the DNS zone loaded on the "primary" DNS servers: the Registrant, the Registrar, or a third party DNS operator.” I object to this phrasing, as it suggest an entity performs it’s role as DNS-operator as part of another role he might play. It’s always the DNS-operator and only the DNS-operator that maintains the DNS zone. An entity can act as both registrant AND DNS-operator, registrar AND DNS-operator, or as a standalone DNS-operator, but an entity never maintains a zone in any other role than as DNS-operator. They should be clearly separated to keep roles and entities clearly defined. This whole section need a thorough review on definitions of roles and entities performing multiple roles. 2.1. Definitions: "After a domain has been registered, one of three parties will maintain the DNS zone loaded on the "primary" DNS servers: the Registrant, the Registrar, or a third party DNS operator.” Again, BY DEFINITION a registrar NEVER IS a DNS-operator, and a registrant NEVER IS a DNS-operator. A DNS-operator is a role that may be performed by an entity that ALSO acts in an administrative role as registrar, registrant, or neither. Registrars and registrants are administrative roles, not technical and not entities. The only way to solve this is to make a DNS-operator an administrative role as well, separate from any other RRR role. I can probably help with some text here. Please read section II-B of this whitepaper for inspiration: https://www.sidnlabs.nl/downloads/wp_2013_EPP-keyrelay_v1.en.pdf 3.2 Establishing a Chain of Trust: This is the section where I have most problems with. The bootstrapping of a secure delegation can never be done over an insecure channel such as DNS without a chain of trust for polling the initial key. Unfortunately, I have not followed the discussions for RFC8078, but when I read that now, I think paragraph 3.3 and 3.5 from RFC8078 are a terrible mistake security wise, and a downgrade from previous practice. I believe that insertion of the first key at the parent should always have been over a secure channel, or confirmed over a secure channel, and in the absence of a chain of trust in DNS prior to a secure delegation, the only way to do that is over the secure administrative channel such as EPP or another proven secure channel which DNS without DNSSEC validation is not. I challenge RFC8078 that it probably had too little review from security folks, and I don’t want to make the same mistake here, which makes it even less secure by saying "Once the Registrar sees these records it SHOULD start acceptance processing.” No way. It should never accept a security proof or security inception process over an insecure channel. Also, the introduction of this document only states "Update DS records” which I agree with, but Establishing a Chain of Trust is not updating but bootstrapping. 4.1 Authentication This chapter starts correctly with mentioning of publication of CDS/CDNSKEY records, but continues from section 4.2 onwards only mentioning CDS ignoring explanation what happens with CDNSKEY. Other comments: There are still some sections in this document that contain placeholders for text. In it’s current form, I challenge the intended status of "standards track”. I would say it reads more like a problem statement with it’s proposed processes to solve issues of inconvenience rather than a document that defines a BCP or makes definitions. I’d say there is still work to do, and I can probably help with some definitions, but let’s first start the discussion on what this document wants to define. Regards, - -- Antoin Verschuren Tweevoren 6, 5672 SB Nuenen, NL M: +31 6 37682392 signature.asc Description: Message signed with OpenPGP using GPGMail _
[regext] Preparing for IETF 100
Dear Working group, It’s time to start planning for IETF 100 in Singapore. To be able to judge if we need a working session, we have 2 questions for you 1. Please submit agenda items to the list. 2. Please indicate if you need working time or update time for your item. Since we need to request meeting slots within a fortnight please submit your discussion items before friday 22th so we can discuss if: 1. We can discuss items in a interim meeting before IETF 100 and only need 1 update session. 2. We need both a working session and a short update session for IETF 100. 3. Or we can do with one longer joint working/update session. Thanx, Jim and Antoin - -- Antoin Verschuren Tweevoren 6, 5672 SB Nuenen, NL M: +31 6 37682392 signature.asc Description: Message signed with OpenPGP using GPGMail ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
[regext] Preparing for IETF 100
Dear Working group, It’s time to start planning for IETF 100 in Singapore. To be able to judge if we need a working session, we have 2 questions for you 1. Please submit agenda items to the list. 2. Please indicate if you need working time or update time for your item. Since we need to request meeting slots within a fortnight please submit your discussion items before friday 22th so we can discuss if: 1. We can discuss items in a interim meeting before IETF 100 and only need 1 update session. 2. We need both a working session and a short update session for IETF 100. 3. Or we can do with one longer joint working/update session. Thanx, Jim and Antoin - -- Antoin Verschuren Tweevoren 6, 5672 SB Nuenen, NL M: +31 6 37682392 signature.asc Description: Message signed with OpenPGP using GPGMail ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] Preparing for IETF 100
Hi all, So far, we only had one reply from Roger for agenda items. With one of the items for a working session being discussed in an Interim meeting before IETF100, this seems like we will not have enough topics to justify a full working session during IETF100. This feels a bit contradictory to the desire to have a seperate working session. We will probably opt for one longer update session where the additional time will be dedicated to working items. Any thoughts? Any more agenda items? Jim and Antoin - -- Antoin Verschuren Tweevoren 6, 5672 SB Nuenen, NL M: +31 6 37682392 Op 20 sep. 2017, om 17:55 heeft Roger D Carney <rcar...@godaddy.com> het volgende geschreven: > Good Morning, > > I would like to suggest the following agenda items for the working session: > The Validate draft > Registry Mapping and Launch Phase Listing > > And for updates: > Fee > Validate > Interim Meetings > > > Thanks > Roger > > > -Original Message- > From: regext [mailto:regext-boun...@ietf.org] On Behalf Of Antoin Verschuren > Sent: Friday, September 15, 2017 8:30 AM > To: Registration Protocols Extensions <regext@ietf.org> > Subject: [regext] Preparing for IETF 100 > > Dear Working group, > > It’s time to start planning for IETF 100 in Singapore. > To be able to judge if we need a working session, we have 2 questions for you > > 1. Please submit agenda items to the list. > 2. Please indicate if you need working time or update time for your item. > > Since we need to request meeting slots within a fortnight please submit your > discussion items before friday 22th so we can discuss if: > > 1. We can discuss items in a interim meeting before IETF 100 and only need 1 > update session. > 2. We need both a working session and a short update session for IETF 100. > 3. Or we can do with one longer joint working/update session. > > Thanx, > > Jim and Antoin > > - -- > Antoin Verschuren > > Tweevoren 6, 5672 SB Nuenen, NL > M: +31 6 37682392 > > > > > > > ___ > regext mailing list > regext@ietf.org > https://www.ietf.org/mailman/listinfo/regext signature.asc Description: Message signed with OpenPGP using GPGMail ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] Request for Working Group Last Call for draft-ietf-regext-allocation-token
James,
Jim and I were going to send out a formal WGLC on this document, but we didn’t
see a reply to this extensive review yet.
What do you want us to do, wait for you to have treated Patrick’s comments, or
consider them as part of WLC (Which may have a deadline)?
Jim and Antoin
- --
Antoin Verschuren
Tweevoren 6, 5672 SB Nuenen, NL
M: +31 6 37682392
Op 21 nov. 2017, om 05:40 heeft Patrick Mevzek <p...@dotandco.com> het volgende
geschreven:
> Hello James and Kal,
>
> Please find below my comments on your draft.
>
> Abstract: remove "or code" in "an allocation token or code", as this is
> not repeated after and does not add value.
>
> The introduction needs to be rephrased, multiple sentences did not have
> sense to me:
>
> "This mapping, an
> extension to EPP object mappings like the EPP domain name mapping
> [RFC5731], for passing an allocation token one of the EPP transform
> commands including create, update, and transfer."
>
> There is no verb at all: This mapping... for passing...
> A "to" is probably missing: an allocation token TO one of the EPP ...
>
> This sentence seems overly complex to say what it says:
> The allocation
> token is known to the server to authorize a client that passes a
> matching allocation token with one of the supported EPP transform
> commands.
> Why not something simpler like:
> A client must pass an allocation token known to the server to be
> authorized to use one of the supported EPP transform commands.
>
> This is not clear technically: The allocation token MAY
> be returned to an authorized client for passing out-of-band to a
> client that uses it with an EPP transform command.
>
> Two clients seem defined here, are they the same one or not? If not,
> what is the difference?
>
>
> 1. Introduction
>
> Maybe make more clear if the allocationToken can be used to do
> operations on some existing objects by a registrar not being its current
> sponsor. Is this the goal, or just something possible among other
> things, or not at all?
>
>
> In 2.1 Inconsistent case: sometimes "Allocation Token", sometimes
> "allocation token"
>
> This does not seem clear: The server MUST have
> the allocation token for each object to match against the allocation
> token passed by the client to authorize the allocation of the object.
>
> I believe that you want to say that the allocation token must be checked
> on the server and match the expected value. But no need to overspecify
> things the server may not even have the allocation token stored, it can
> be the hash of the object ID and a secret hence checked dynamically.
>
>
>
> 3.1.1
> There is a gap between the feature here and the introduction.
> The introduction says:
> "authorization to
> allocate an object using one of the EPP transform commands including
> create, update, and transfer."
>
> (and this sentence is not clear by itself, why is an update or a
> transfer
> now an allocation?)
>
> where in the check command:
> Clients can
> check if an object can be created using the allocation token.
>
> So how can clients check if an object could be updated or transfered
> using the given allocation token, besides trying to do it and seeing if
> it fails or not? But since create has a specific command to test the
> allocation token (with check), why not the others?
> Otherwise the introduction will need to be changed to speak only about
> create, which then will make more sense with its name ("allocation") as
> otherwise if it really needs to be generic accross multiple actions I
> would suggest something more like "authorization token" with the risk of
> clashing with EPP core authInfo concept.
>
> Is there a reason to put the result in the domain:reason node instead
> of having really an allocationToken extension in the domain:check reply
> which will store data specific to it?
> (like it is done for the fees extension, or launchphase, etc.)
>
>
> 3.1.2
> I would like more explanation on what the allocationToken there
> represents, especially considering the gap I see between what is in the
> description and the check command as explained above.
>
> When doing domain:info, is the allocation token returned the one used to
> do the create? Or is it the one to be used to do a transfer or update?
> What if there are not the same?
> What is in fact the use case of providing to a registrar an allocation
> token that way, when it is said at the beginning that such allocation
> tokens are retrieved out of bound?
> This is also related to what we see on the field with some registries
> tha
[regext] Additional WGLC for draft-ietf-regext-launchphase
Hi all, This ia an additional Working Group Last Call for the Launchphase document draft-ietf-regext-launchphase. You can find the latest version of the document here: https://datatracker.ietf.org/doc/draft-ietf-regext-launchphase/ The authors did an excellent job correcting issues that came up during the IESG review. However, some of the comments, especially the comments made by Ben Campbell (See the change log in the document) made it necessary to change normative language, which may have substantially changed some intent in the document. We think it’s all fine, but to be sure we didn’t miss anything, we will make an additional WGLC. Since it’s holiday season, this WGLC will end January 5th. Please review the changes made to the document, and let us know before January 5th if you have any comments. Regards, Jim and Antoin - -- Antoin Verschuren Tweevoren 6, 5672 SB Nuenen, NL M: +31 6 37682392 signature.asc Description: Message signed with OpenPGP using GPGMail ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] Request for Working Group Last Call for draft-ietf-regext-change-poll
James, Same for this one. Jim and I were going to send out a formal WGLC on this document, but we didn’t see a reply to this extensive review yet. What do you want us to do, wait for you to have treated Patrick’s comments, or consider them as part of WGLC (Which may have a deadline)? Jim and Antoin - -- - -- Antoin Verschuren Tweevoren 6, 5672 SB Nuenen, NL M: +31 6 37682392 Op 23 nov. 2017, om 06:42 heeft Patrick Mevzek <p...@dotandco.com> het volgende geschreven: > Hello James and Kal, > > Here are my comments on the draft: > > The abstract is almost longer than the introduction, > and I believe it should be the opposite. > > I prefer this sentence in the abstract: > notifying clients of operations on client sponsored > objects that were not initiated by the client through EPP. > > over this one in the introduction: > to notify clients of operations they are not > directly involved in, on objects that the client sponsors. > > I think the given clients are directly involved as they are > the sponsors on the objects being operated. I think it is best > to say something like in the abstract, which is that the goal > of this extension is to notify clients of operations conducted > on objects they sponsor and which were not initiated by them. > (please rephrase that in proper English). > > "Using this extension clients can more easily keep" > A missing "," after extension? > > "a poll message can be inserted" > The whole purpose of the extension is to add these poll messages, > so maybe being more affirmative like "one or more poll messages > are inserted". > > Also, RFC5730 speaks about the poll *command* but otherwise it is > about *service messages*, so it is maybe better to align > the terminology. > > 2.1 > > For transfer, why is the op attribute optional, especially since > it has no default value? > RFC5730 defines 5 transfer sub-operations with no extension possible, > so I believe here the op attribute should be mandatory > > As for restore that has a sub operation case too, I think the same > reasoning apply. > > 2.2 Maybe a little rephrasing to be clearer, I suggest: > "The element defines who executed the operation, > for audit purposes." > > Further below, you capitalize who as Who but I see no reason to > do that. > > Then you list 3 possible cases for the content of the who attributes, > but since it is just a normalizedString, the consumer of such poll > messages has no indication in which of these 3 cases we are, or others. > Maybe it would be better to add an attribute to the who element, > like "type" that remains free text but will allow the registry > to explain what the who content is about with such values > as "identifier" (and/or "roid" and/or "gurid" for example°), > "name" or maybe better "individual", and "role", or "batch". > > I found the whole section 2 to not be clear enough. You state that > it is an extension to object mappings and then you discuss only two > attributes, while others are discussed later in section 3. > > > 3.1.2 > > Should be retitled about service messages and poll commands, as this > sentence is wrong: > This extension adds transaction detail of the operations to the EPP >poll response, > There is no poll response, but just a poll response with > a service message it has nothing to do with the info command. > > you say "Object Mapping" with uppercases, and before you > had "object mapping". Please double check the whole documenthe > and apply some uniform formatting. > > This sentence is not clear: > "This extension adds transaction detail of the operations" > Which operations? Why using the term "transaction"? > Did you want instead to clearly speak about "transform > operations" like you do elsewhere. > > changePoll:date : please specify in what timezone it SHOULD > or MUST be. > RFC5731 section 2.4 says about date and times: > Date and time attribute values MUST be represented in Universal > Coordinated Time (UTC) using the Gregorian calendar. > Maybe you should do the same here for homogeneity? > > changepoll:caseId has only two specified values for its type > attribute (UDRP and URS) but if we go back to the abstract > where you listed possible cases, you listed UDRP and URS, > but also court directed actions, and bulk updates. > So why not also add types "court" and "bulk" for example > That would make the informal abstract and the formal technical > specification more closely aligned. > > > >
[regext] Call for adoption: draft-hollenbeck-regext-rdap-object-tag
Hi all, As discussed in Singapore, we have cleaned up our list of action items and moved documents along to the IESG and into working group last call, so we can now adopt new documents. This is a formal adoption request for draft-hollenbeck-regext-rdap-object-tag The draft is available here: https://datatracker.ietf.org/doc/draft-hollenbeck-regext-rdap-object-tag/ Please review this draft to see if you think it is suitable for adoption by REGEXT, and comment to the list, clearly stating your view. Please also indicate if you are willing to contribute text, review, etc. This call for adoption ends 20 December 2017. If there are no objections, and we receive enough consensus for adoption, the chairs will consider this document adopted. Thanks, Your REGEXT co-chairs Jim and Antoin. - -- Antoin Verschuren Tweevoren 6, 5672 SB Nuenen, NL M: +31 6 37682392 signature.asc Description: Message signed with OpenPGP using GPGMail ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
[regext] REGEXT Minutes IETF 100
Hi all, I just uploaded the attached draft minutes from our IETF 100 meeting to the datatracker. If you happen to see any errors in them, please let us know within the coming week, so we can make them final. Thank you very much Alexander for taking the minutes! Jim and Antoin Registration Protocols Extensions (REGEXT) IETF 100, Singapore, Meeting minutes Co-chairs: Jim Galvin, Antoin Verschuren Mailinglist: regext@ietf.org Existing Documents -- Launch Phase is in publication requested - all good so far. Fee Extension (Roger Carney) --- Couple of open questions from implementation - next version (09) is ready to be published (adds just one item to the schema). Two questions: 1) "cd:avail" flag if only a partial set is returned - currently returning 0 (unless full set is given). Jim Gould argues for the opposite (should be 1 even in case of partial responses) - will bring it to the list. 2) classification on the command vs. object level - should be at the object level (proposal to move it up to the object level) - Roger agrees, if someone disagrees Roger will post the two last remaining items to the list, then roll -09 and then ask for WGLC Validate --- -02 was posted in August. Only a handful of comments, and currently looking for implementors. Jim Gould: Option to use it for existing contacts, rather than supplying "new" contacts? Roger: Mainly intended for domain creates Registry Mapping (Roger Carney) --- http://www.verisign.com/assets/epp-sdk/verisign_epp-extension_registry_v01.html Will talk more about it later in the Working Session Milestone Review Back in Chicago, got pushback on new documents from AD - should clean up document queue, 3-5 documents are going to go to IESG before end of year or latest Q1 2018. Discussion goal is to identify whether documents are ready from the WG perspective. 3-5 people required during WGLC to indicate concensus - can be hard to reach "non-authors" because of group size. - Change Poll: Chairs think it is ready, Jacques said they intended to implement Jim: Implementation from Neustar and Verisign. Think it is ready for WGLC - Jim will make a request on the list. Nobody objects against that plan. - Allocation Token: same. - dnsoperator-to-rrr: Needs more review, is not there yet for WGLC. Jim Gould: Did a recent review, and has a concern about lack of addressing of the trust relationship between dns operator and other parties. Jim Galvin (as individual): appreciates the 2 implementation efforts (CIRA and CZ.NIC), however it's difficult for gTLDs to support this for policy reasons. (Is defined out of scope in document). Roger: As Registrar, changing data outside of the registry/registrar loop is problematic for registrars. Communication "along the chain" needs to be figured out. Currently no intention to implement this. Jim (as Chair) notes the Milestone for this document is coming up soon - heads up to document authors. - bundling-registration: Defines just one way / use-case of bundling, but does not cover all options. Suggestion from the Chairs is to make it informational, and move it forward that way. Jiankang Yao: We have significant implementation / operation experience in that under .cn. Scott: If we go to informational, then add an Implementation Status section with the experiences? Ning: If there are other bundling mechanisms / use cases, please feed back to us and we can add them Edmund Chang: Wouldn't that be worthwhile as a standard if it would be subject to IDN bundling only? Jim: No way to enable/disable individual registrations in a bundle, and DNSSEC would need to be dealt with - org/org-ext: Antoin: Documents need a thorough review, but also implementation analysis / experience report. Suggests the authors push for review or more implementation. Ning: reseller draft is implemented, org drafts are not implemented yet, research ongoing on whether implementation feasible. Jim Galvin: Implementations in other contexts? Ning: Registrars and .cn Roger: Never found a reason to implement this Jody: Have no reason to implement this - considers that information that is of no concern to the registry. ICANN option to include it is considered an overkill. Jim Galvin: Falls into same category as the dnsoperator-to-rrr and bundling - whether that's a standards track document or informational candidate. Scott: Since when is implementation required for standards track? Jim Galvin: Wide applicability is, not necessarily implementation, right. Andrew Newton: Don't like the concept "i'm not going to do that" -> "we won't standardize it". Andrew Sullivan: If this WG is not the work to produce one canonical document for a problem, then please point us to where that work is performed. Jim: That's what the IANA extension is for - doesn't mean
[regext] REGEXT Minutes IETF 100
Hi all, I just uploaded the attached draft minutes from our IETF 100 meeting to the datatracker. If you happen to see any errors in them, please let us know within the coming week, so we can make them final. Thank you very much Alexander for taking the minutes! Jim and Antoin Registration Protocols Extensions (REGEXT) IETF 100, Singapore, Meeting minutes Co-chairs: Jim Galvin, Antoin Verschuren Mailinglist: regext@ietf.org Existing Documents -- Launch Phase is in publication requested - all good so far. Fee Extension (Roger Carney) --- Couple of open questions from implementation - next version (09) is ready to be published (adds just one item to the schema). Two questions: 1) "cd:avail" flag if only a partial set is returned - currently returning 0 (unless full set is given). Jim Gould argues for the opposite (should be 1 even in case of partial responses) - will bring it to the list. 2) classification on the command vs. object level - should be at the object level (proposal to move it up to the object level) - Roger agrees, if someone disagrees Roger will post the two last remaining items to the list, then roll -09 and then ask for WGLC Validate --- -02 was posted in August. Only a handful of comments, and currently looking for implementors. Jim Gould: Option to use it for existing contacts, rather than supplying "new" contacts? Roger: Mainly intended for domain creates Registry Mapping (Roger Carney) --- http://www.verisign.com/assets/epp-sdk/verisign_epp-extension_registry_v01.html Will talk more about it later in the Working Session Milestone Review Back in Chicago, got pushback on new documents from AD - should clean up document queue, 3-5 documents are going to go to IESG before end of year or latest Q1 2018. Discussion goal is to identify whether documents are ready from the WG perspective. 3-5 people required during WGLC to indicate concensus - can be hard to reach "non-authors" because of group size. - Change Poll: Chairs think it is ready, Jacques said they intended to implement Jim: Implementation from Neustar and Verisign. Think it is ready for WGLC - Jim will make a request on the list. Nobody objects against that plan. - Allocation Token: same. - dnsoperator-to-rrr: Needs more review, is not there yet for WGLC. Jim Gould: Did a recent review, and has a concern about lack of addressing of the trust relationship between dns operator and other parties. Jim Galvin (as individual): appreciates the 2 implementation efforts (CIRA and CZ.NIC), however it's difficult for gTLDs to support this for policy reasons. (Is defined out of scope in document). Roger: As Registrar, changing data outside of the registry/registrar loop is problematic for registrars. Communication "along the chain" needs to be figured out. Currently no intention to implement this. Jim (as Chair) notes the Milestone for this document is coming up soon - heads up to document authors. - bundling-registration: Defines just one way / use-case of bundling, but does not cover all options. Suggestion from the Chairs is to make it informational, and move it forward that way. Jiankang Yao: We have significant implementation / operation experience in that under .cn. Scott: If we go to informational, then add an Implementation Status section with the experiences? Ning: If there are other bundling mechanisms / use cases, please feed back to us and we can add them Edmund Chang: Wouldn't that be worthwhile as a standard if it would be subject to IDN bundling only? Jim: No way to enable/disable individual registrations in a bundle, and DNSSEC would need to be dealt with - org/org-ext: Antoin: Documents need a thorough review, but also implementation analysis / experience report. Suggests the authors push for review or more implementation. Ning: reseller draft is implemented, org drafts are not implemented yet, research ongoing on whether implementation feasible. Jim Galvin: Implementations in other contexts? Ning: Registrars and .cn Roger: Never found a reason to implement this Jody: Have no reason to implement this - considers that information that is of no concern to the registry. ICANN option to include it is considered an overkill. Jim Galvin: Falls into same category as the dnsoperator-to-rrr and bundling - whether that's a standards track document or informational candidate. Scott: Since when is implementation required for standards track? Jim Galvin: Wide applicability is, not necessarily implementation, right. Andrew Newton: Don't like the concept "i'm not going to do that" -> "we won't standardize it". Andrew Sullivan: If this WG is not the work to produce one canonical document for a problem, then please point us to where that work is performed. Jim: That's what the IANA extension is for - doesn't mean
Re: [regext] WGLC: draft-ietf-regext-org-02
Apologies for not having stepped into this discussion before. Having to reread all the treads and all changes during WGLC now the WGLC has ended I can understand Patrick’s concerns. Since I was one of the many voices changing the reseller drafts into the org drafts I will try to explain my concerns I had at the time. I felt I was the only voice in the dessert at the time, but now that I see all the changes, I will try to explain again. This is my personal voice, so chair hat off. The reason I didn’t support the reseller drafts was twofold: 1. I saw the need for some registries to give organizations other than the traditional Registrars and Registrants a role in the registration process, but this was not limited to resellers. The discussion started because resellers were complaining that their name didn’t show up in the whois for specific registrations, and Registrars were complaining that Registrants of those registrations would call them in stead of their reseller. Registrants simply forgot who they had signed a contract with, so they looked it up in whois. Registrars wanted to list their reseller in whois. Appart from resellers, I could see other roles in the future. Working on Keyrelay, and the emerging dnsoperator-to-rrr draft, dns-operators would be another organization registries might want to give special rights to, for example to change NS records or roll DNSKEY material for domains they were responsible for. If we were to give every organization role it’s own extension, that could lead to a forrest of organization types each with their own specification. 2. Coming from way back when we still had only admin-c, tech-c and billing-c contacts (which btw, were often one and the same person, so 1 NIC-handle) and no registrars, I rejected the business marketing thought that an organization IS, and can only be a one of a choice between Registry, Registrar, Registrant, Reseller or DNS-operator. An organization can play a role as Registrar for one registration, but could play the role of a DNS-operator only for another registration. It’s NOT: Once tagged a reseller, always a reseller. For our purpose of registering registrations, the contractual business relationship organizations have between each other is of no matter. We only need to know the role an organization plays for a specific registration. Trick question for bonus points: who IS a Registry, Registrar and Registrant for verisign.nl ? So we can never "tag” an organization as: This one IS a Registrar, this one IS always a reseller. It might be so that an organization can only perform a role as a Registrar for specific registries once he is accredited by ICANN or has signed a registrar agreement with a non gTLD, but that bookkeeping should not be part of EPP. EPP is a provisioning protocol that only administers registrations of Internet identifiers, it is not a CRM system. So I share Patricks concern during WGLC regarding: --- > I guess it's the fact > that roles are defined as properties of the organization and at the same > time as properties of the link? Yes, that is one troublesome point I raised months ago. — Having said that, I can also understand James reasoning that if any organization could perform any role, why not simplify even more and also administrate Registrars and Registrants as organizations. But this leads to the basic bookkeeping challenge of when to give an organization rights to register with the registry system or perform other tasks. I assume this is the reason why one would like to tag an organization as "Registrar” for that specific registry only, because that Registry wants to know if that organization has signed a registrar agreement to give registration rights in the registry system. And tag an organization as a reseller to give him f.e. rights to perform info commands for domains. So while I understand the tagging of an organization for this purpose, I believe it should not be set through EPP. It’s only the Registry itself that can set this tag internally in the registry system after all the CRM and contract thingies have been verified. So my major question is: Can we still remove the elements from the organization object and only use the in the domain objects ? What would it break? Or could we at least have text that this role element can never be set by a random EPP command for an organization but is always set by the Registry? (so an info command would show it, but a create or update could never set it?) Or is this local policy and do we need to give guidance to registries as to why, when and how to set this in a BCP? - -- Antoin Verschuren Tweevoren 6, 5672 SB Nuenen, NL M: +31 6 37682392 Op 24 mei 2018, om 15:30 heeft Gould, James
Re: [regext] WGLC: draft-ietf-regext-org-02
Oh, and when reviewing, I found another completely different issue, and that is with object ownership. I see a role can have an optional parentID, but what if my organization is reseller for more than one registrar within the same registry, and I want multiple reseller roles with a different parentID, which registrar is then entitled to change my organization data? I can also see an issue of object hijacking. Suppose I’m a reseller for registrar A, but my organization is also dns-operator for domains at registrar B. I would think registrar B would not be allowed to change my organization object data that is maintained by registrar A. I could ask registrar A to add my dns-operator role type so registrar B could link my object to domains maintained by him, but registrar A could refuse that. Or should I have a different organization object at each registrar? I think that would not make things more orderly, and I could end up with a number of organization objects for my 1 organization in the same registry.. - -- Antoin Verschuren Tweevoren 6, 5672 SB Nuenen, NL M: +31 6 37682392 Op 25 mei 2018, om 22:38 heeft Antoin Verschuren <i...@antoin.nl> het volgende geschreven: > Hi James, > > Thank you for explaining. I can understand your reasoning now. It’s the > client that authorizes the role an organization can have before it links a > domain in that role, except for the registrar role that is set by the server > based on local policy. > I would only make it more clear in the text that an organization can acquire > more than one role, and that the role type doesn’t say anything about an > organization itself other than it’s current abilities. > I suggest changing sections 3.2 and 3.2.1 (most important is the change of > would to could): > > 3.2. Organization Roles > >The organization roles are used to represent the relationship an >organization could have. Its corresponding element is . > > 3.2.1. Role Type > >An organization could support a list of roles. An organization could have > multiple >roles with a different role type. See Section 7.3 for a list of role type > values. >Its corresponding element is . > > (sorry for the layout mess up by my email client) > > Oh, and shouldn’t the registry in section 7.3 be called "Role Type Values > Registry" in stead of "Role Values Registry" ? > And if I can make another suggestion, I would certainly add a dns-operator as > an initial registry entry in section 7.3.2: > Value: dns-operator > > Description: The entity object instance represents a third-party > DNS operator that maintains the name servers and zone data on > behalf of a registrant.. > > Registrant Name: IESG > > Registrant Contact Information: i...@ietf.org > The justification being that I’ve seen that term used more in wishful > presentations than privacyproxy. > > - -- > Antoin Verschuren > > Tweevoren 6, 5672 SB Nuenen, NL > M: +31 6 37682392 > > > > > > > Op 25 mei 2018, om 20:27 heeft Gould, James >
[regext] Preparing for Montreal
Hi all, It is time for us to start thinking of meeting in Montreal. With 6 out of 9 millstones on our list in a shepherd writeup status, the chairs would like to know if there are enough topics left for us to justify a work session in Montreal and get a sense of the length for our regular meeting slot. We need to send in a meeting request next week, so our question to you is: -Do you have agenda items for Montreal? -Do you have items to be discussed in a work session? Our judgement is that we have 3 active drafts left on our milestones list for which there is little discussion left, mostly also because the focus has been on the 6 WGLC documents for the past period and we have little resources (in other words: we understand you could do with a re-bootstrapping ;-)). There are 2 topics that may justify a work session as far as we are aware: -The registry mapping discussion -Poll messages with unhanded namespaces But since there are no related drafts yet for these discussions that need to be presented in our regular session, we could also decide to use 1 meeting slot where we take the first half hour for our regular session for status updates to our milestones, and the rest of our meeting to these topics if someone is willing to lead them. So please let us know if you have any agenda items. Jim and Antoin. - -- Antoin Verschuren Tweevoren 6, 5672 SB Nuenen, NL M: +31 6 37682392 ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
[regext] Preliminary agenda items for IETF 102 Montreal
Hi all, Below you find our preliminary agenda for Montreal. We still have some time left in our regular session to talk about new drafts or requests for new work items, so if you want to discuss something, please let us know: Registration Protocols Extensions (REGEXT) IETF 102, Montreal, CA, Agenda Co-chairs: Jim Galvin, Antoin Verschuren Mailinglist: regext@ietf.org * Session I, Work session. ?? 2h 1. Unhandled Namespaces (Jim Gould, 40 min.) 2. Registry Mapping (Roger Carney, 40 min.) 3. RDAP Search Capabilities and Authentication (Francisco Arias, 40 min.) * * Session II, Regular WG meeting session. ?? 1h 1. Welcome and Introductions (5 minutes) i. Jabber scribe ii. Notes scribe iii. NOTE WELL 2. Existing Document Status 2.a. IETF Last call (2 minutes) i. Registration Data Access Protocol (RDAP) Object Tagging https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-object-tag/ 2.b. Documents past WGLC (5 minutes) i. Allocation Token Extension for the Extensible Provisioning Protocol (EPP) https://datatracker.ietf.org/doc/draft-ietf-regext-allocation-token/ ii. Change Poll Extension for the Extensible Provisioning Protocol (EPP) https://datatracker.ietf.org/doc/draft-ietf-regext-change-poll/ iii. Extensible Provisioning Protocol (EPP) Organization Mapping https://datatracker.ietf.org/doc/draft-ietf-regext-org/ Organization Extension for the Extensible Provisioning Protocol (EPP) https://datatracker.ietf.org/doc/draft-ietf-regext-org-ext/ 2.c. Other documents on our milestones list (5 minutes) 2.d. New work items 3. Work session summaries (15 minutes) i. Unhandled Namespaces (Jim Gould) ii. Registry Mapping (Roger Carney) iii. RDAP Search Capabilities and Authentication (Francisco Arias) 4. Charter update (5 min.) 5. AOB * The preliminary agenda is due next week. Regards, Jim and Antoin - -- Antoin Verschuren Tweevoren 6, 5672 SB Nuenen, NL M: +31 6 37682392 signature.asc Description: Message signed with OpenPGP using GPGMail ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] Proposed Revision to our Charter
Ok, perhaps some clarification. The broadening of the charter is not to broaden the scope of EPP or RDAP. Both EPP and RDAP have always been protocols to serve any "internet infrastructure identifier registry”, be it TLD’s RIR’s, ENUM registries, 2nd/3th/4th/.. level domain registries, so currently basically domains or IP’s or anything that does something DNS, but we have never limited the protocols to be used by any other registry that could arise and saw it fit to use it for their provisioning. We have chosen this term to avoid this working group to only think of policy limited gTLD’s as the only usage for EPP and RDAP, which is not true. ccTLD’s, sTLD’s, RIR’s and ENUM registries also use EPP and/or RDAP. The only change to the charter is that we previously had only one permitted extra work item of the dns-operators draft beyond EPP and RDAP protocol work, because we had a long milestone list that our AD wanted us to do first before we took on new work items. Now that our milestone list shortens, we have more time to take on this additional work, but as the charter proposal says, it should be limited to work related to the provisioning of "internet infrastructure identifier registries” that use EPP or RDAP, and the extra limitation is our AD needs to approve the topic as being in scope. I hope this helps, and if you have a better suggestion for scoping or wording, we’ll be happy to hear. We have put this proposed charter out here for formal discusion on the mailinglist and we will also have an item on our agenda in Montreal to discuss. - -- Antoin Verschuren Tweevoren 6, 5672 SB Nuenen, NL M: +31 6 37682392 Op 13 jun. 2018, om 23:39 heeft Andrew Newton het volgende geschreven: > Thanks for the clarification, Roger. > > The file formats seem like appropriate work to me. That said, the > wording of the proposed charter seemed to indicate to me there was a > broader motivation. If there is such, it be best if it were stated. > > -andy > > On Wed, Jun 13, 2018 at 11:52 AM, Roger D Carney wrote: >> Good Morning, >> >> >> >> I was definitely not thinking of two working groups. >> >> >> >> The focus of the WG is EPP and RDAP extensions. The additional suggested >> wording just adds on the ability to take on relevant (as determined by WG >> and AD) work (e.g. Third Party DNS Operator…). My suggestion was not to >> exclude, but to provide more focused wording. Maybe that wording is better, >> change the entire sentence to state: “The working group may also take on >> relevant (as determined by WG and AD) work, beyond the EPP and RDAP >> protocols.” >> >> >> >> Andy, I think your original question that you posted earlier in the week is >> what needs to be answered first, paraphrasing “what is the motivation for >> this change”. Several others I think have basically asked the same question. >> >> >> >> I don’t think I was the one asking for the charter change but here are my >> thoughts on why I see a change being beneficial. >> >> >> >> To me this started with the proposed Third Party DNS Operator document. At >> one point the Charter was updated to add in this specific item (our current >> Charter). Then over the past year some discussions were had on standardizing >> the files that registries and registrars share (Unavailable Names, >> Non-Standard/Premium Domain Fees, Invoicing) which lead into the discussion >> of standardizing the storage of these files and other items (reporting comes >> to mind). Today different registries have different web portals and ftp >> sites to get this information from and different registrars request the >> information in different formats. Many registries and registrars have agreed >> that they would like to see a much better experience here. These topics do >> not fit into the EPP/RDAP focus of our current charter but the people with >> the most interest and expertise in these ideas are in this WG. >> >> >> >> >> >> Thanks >> >> Roger >> >> >> >> >> >> -Original Message- >> From: Andrew Newton [mailto:a...@hxr.us] >> Sent: Wednesday, June 13, 2018 9:45 AM >> To: Roger D Carney >> Cc: Registration Protocols Extensions >> Subject: Re: [regext] Proposed Revision to our Charter >> >> >> >> On Wed, Jun 13, 2018 at 10:35 AM, Roger D Carney >> wrote: >> >>> Good Morning, >> >>> >> >>> >> >>> >> >>> I agree with those saying this new wording seems a bit broad, what if >> >>> "...relat
[regext] Publication has been requested for draft-ietf-regext-allocation-token-08
Antoin Verschuren has requested publication of draft-ietf-regext-allocation-token-08 as Proposed Standard on behalf of the REGEXT working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-regext-allocation-token/ ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] WGLC: draft-ietf-regext-org-02
Op 27 mei 2018, om 21:23 heeft Patrick Mevzek het volgende geschreven: > This is covered I think in ICANN world by section 1.4.2 of the whois > specification: > > "Additional data elements can be added at the end of the text format outlined > below.” Ah yes, let’s take the solution of "we can put everything in one non-parseble TXT record like DNS can do too if we fail proper design and really want to” ;-) Sorry for the sarcasm Patrick, but that one was a too open goal ;-) > This is all true, probably, but how does it goes from there to "these > operators need to exist as object in the registry database and be made under > control of the registrars"? This sidestep many other points, like, one > dns-operator for example, could be operator for domain names sponsored by > registrar A and registrar B. Will both registrar A and B need to create an > organization object for this same and only dns-operator organization? What > exactly does this benefit to? That was my question and worry too, and the answer unfortunately is yes, as ownership of an object needs to be clear to prevent hijacking or no responsibility for data. It’s a choice between two bad’s I agree, but having an organization in the DB more than once under different registrars with different ID’s is less bad than having objects nobody maintains or fights over. > In a GDPR world you need more and more to be very specific about the data you > collect, its use, and how you keep it. While it does not apply exactly as is > here, I still fail to see why the registry database need to be populated with > all this data. You forget to see that this will benefit registries that want to do the right thing where they are now limited by protocol. It allows innovation. I’ve seen registries that want to add reseller data in whois/RDAP at their registrar’s request, registries that want dns-operators to be able to roll their registrant’s DNSSEC keys, they want to be transparent as tho which organization has extended RDAP access, etc. And the registrars are still in control over who they trust with these limited registry credentials, but in the end they will save costly customer support and have more extended service if they automate. > And while I can understand James argument and design I think we are making > things over complex without direct benefit, for what I understood the only > use case applicable on the table is "storing reseller data in registry > database (and maybe showing it in whois)". > For such a simple need, I think we are over-designing stuff. If that were the only use case, I would agree with you. It may look like overdesigning now if that were the only use case, but if we don’t add structure now, it will be hard to go back once unstructured objects are already populated. We took the challenge of doing more work now, to have quicker innovation later. And I see more use cases than just the reseller one. regards, - -- Antoin Verschuren Tweevoren 6, 5672 SB Nuenen, NL M: +31 6 37682392 - -- Antoin Verschuren Tweevoren 6, 5672 SB Nuenen, NL M: +31 6 37682392 signature.asc Description: Message signed with OpenPGP using GPGMail ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] WGLC: draft-ietf-regext-org-02
Op 28 mei 2018, om 22:48 heeft Patrick Mevzek het volgende geschreven: > In your quote you missed the other part which is basically: all domain names > are not under ICANN policies. I didn’t want to go in that discussion, but I’m on your side on that one. > So for all other TLDs currently can you let me know which protocol > limitations currently forbid registry to add formatted content in their whois > or, let us say just decide to implement RDAP to start with? Do you really > think there are almost none because of protocol limitations, especially in > the EPP channel, or maybe for other reasons? Perhaps it’s not only protocol limitations, or perhaps limitation the wrong word, it’s more the pinpointed ICANN RRR model I think that can only be provisioned for now. I remember a CENTR meeting where ccTLD’s tried to get consensus over if we could harmonize EPP extensions so registrars would not have to code differently for every TLD. This was before EPPEXT existed. We all thought this would be a good idea. But half the registries concluded that they wanted to stick to their own extensions because they felt local legislation or their local constituencies required them so, and the other half had the standpoint that they would only implement as followers, after extensions would be standardized. Again Patrick, I share your concern of complexity, and we shouldn’t build something nobody uses. I also shared your concern for double labeling both at the organization and link level, but James managed to convince me it’s a choice between two bad’s where the responsibility of registrars over records they maintain outscores double entries in the database for organizations that do anything for anybody. The reseller draft was originally requested and supported by cnnic, sidn and dns belgium who also had the intend to implement. If not this standard then their own extension. Other registries didn’t immediately acknowledge the need for resellers unless mandated by (ICANN) policy, but there was consensus that if we were to standardize something to accommodate resellers, it should be reusable for other emerging "Internet identifier registration related roles" as well. This was not only TLD registries that had an opinion, and I remember some hesitation especially by ICANN registrars as well because they didn't want extra work, but third party dns-operators, ICANN related policy makers, RIR’s, registrants and plain IETF protocol guardians also have an equal voice in the IETF process, even though they don’t implement. - -- Antoin Verschuren Tweevoren 6, 5672 SB Nuenen, NL M: +31 6 37682392 signature.asc Description: Message signed with OpenPGP using GPGMail ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
[regext] Publication has been requested for draft-ietf-regext-rdap-object-tag-03
Antoin Verschuren has requested publication of draft-ietf-regext-rdap-object-tag-03 as Best Current Practice on behalf of the REGEXT working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-object-tag/ ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] Preparing for Montreal
Dear all, We have requested a 2 hour work session, and a 1 hour working group meeting slot. Roger: Excelent topics, but we need somebody to lead the discussion. We assume you can lead the Registry Mapping discussion during the work session? How about the Poll Messages w/ Unhandled Namespaces? - -- Antoin Verschuren Tweevoren 6, 5672 SB Nuenen, NL M: +31 6 37682392 Op 25 mei 2018, om 17:25 heeft Roger D Carney het volgende geschreven: > Good Morning, > > Do we need to discuss our next documents in our regular meeting slot? > > For the regular meeting, I would like to give an update from the interim > meeting(s). > > I like the two suggested topics for the working session: Registry Mapping and > Poll Messages w/ Unhandled Namespaces > > With all the focus from ICANN on RDAP, I wonder if we should also discuss > what is left to make RDAP functional for ICANN (e.g. authentication methods, > searching, etc.). > > I think maybe an hour for each session. Again I would like to see the working > session before the regular meeting so that we can provide updates at the > regular meeting. > > > Thanks > Roger > > > -Original Message----- > From: regext [mailto:regext-boun...@ietf.org] On Behalf Of Antoin Verschuren > Sent: Friday, May 25, 2018 1:25 AM > To: regext > Subject: [regext] Preparing for Montreal > > Hi all, > > It is time for us to start thinking of meeting in Montreal. > With 6 out of 9 millstones on our list in a shepherd writeup status, the > chairs would like to know if there are enough topics left for us to justify a > work session in Montreal and get a sense of the length for our regular > meeting slot. > We need to send in a meeting request next week, so our question to you is: > -Do you have agenda items for Montreal? > -Do you have items to be discussed in a work session? > > Our judgement is that we have 3 active drafts left on our milestones list for > which there is little discussion left, mostly also because the focus has been > on the 6 WGLC documents for the past period and we have little resources (in > other words: we understand you could do with a re-bootstrapping ;-)). > There are 2 topics that may justify a work session as far as we are aware: > -The registry mapping discussion > -Poll messages with unhanded namespaces > But since there are no related drafts yet for these discussions that need to > be presented in our regular session, we could also decide to use 1 meeting > slot where we take the first half hour for our regular session for status > updates to our milestones, and the rest of our meeting to these topics if > someone is willing to lead them. > > So please let us know if you have any agenda items. > > Jim and Antoin. > > - -- > Antoin Verschuren > > Tweevoren 6, 5672 SB Nuenen, NL > M: +31 6 37682392 > > > > > > > ___ > regext mailing list > regext@ietf.org > https://www.ietf.org/mailman/listinfo/regext > ___ > regext mailing list > regext@ietf.org > https://www.ietf.org/mailman/listinfo/regext signature.asc Description: Message signed with OpenPGP using GPGMail ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] Potential Topic for IETF-102: RDAP Search Capabilities
Scott, Sounds like an excellent idea. Since it’s new work, I assume we would like to have that discussion in our "work session”?, and Francisco is willing to lead that discussion? - -- Antoin Verschuren Tweevoren 6, 5672 SB Nuenen, NL M: +31 6 37682392 Op 30 mei 2018, om 20:19 heeft Hollenbeck, Scott het volgende geschreven: > Folks, one of the questions that came up during a presentation at the recent > Registration Operations Workshop was focused on RDAP's search capabilities > and if they were sufficient for use in the gTLD community. Francisco Arias > has some thoughts on functional requirements, so I thought it might be a good > idea to talk about the topic at IETF-102. Francisco has confirmed that he's > available and can talk to the topic. Can we consider adding this topic to our > meeting agenda? > > Scott > > ___ > regext mailing list > regext@ietf.org > https://www.ietf.org/mailman/listinfo/regext signature.asc Description: Message signed with OpenPGP using GPGMail ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
[regext] Preliminary agenda
Hi All, We’re early this time, but please find our preliminary agenda for Singapore attached. We have one 2 hour slot in Singapore, that we will use for both the working session and the updates. The questions we have for the group: -Would you like to have the working session first or the regular update session first? Pros for having the working session first would be that we could have an update during the regular session, but the con would be that this would start the update session later. Pros for having the update session first would be that we could spend all excess time to the working session. Please let us know what you think would be best. -If there are any more agenda items, please let us know. Registration Protocols Extensions (REGEXT) IETF 100, Singapore, Agenda Co-chairs: Jim Galvin, Antoin Verschuren Mailinglist: regext@ietf.org Update session, first hour: 1. Welcome and Introductions (5 minutes) i. Jabber scribe ii. Notes scribe iii. NOTE WELL 2. Existing Document Status i. Publication requested, status (1 minute) https://datatracker.ietf.org/doc/draft-ietf-regext-launchphase/ 3. Fee Extension (Roger Carney, 5 minutes) https://datatracker.ietf.org/doc/draft-ietf-regext-epp-fees/ 4. Validate Extension (Roger Carney, 5 minutes) https://datatracker.ietf.org/doc/draft-ietf-regext-validate/ 5. Review of milestones status (15 minutes) https://datatracker.ietf.org/group/regext/about/ i. https://datatracker.ietf.org/doc/draft-ietf-regext-change-poll/ Ready? ii. https://datatracker.ietf.org/doc/draft-ietf-regext-allocation-token/ Ready? iii. https://datatracker.ietf.org/doc/draft-ietf-regext-dnsoperator-to-rrr-protocol/ Review? iv. https://datatracker.ietf.org/doc/draft-ietf-regext-bundling-registration/ Informational? v. https://datatracker.ietf.org/doc/draft-ietf-regext-org/ https://datatracker.ietf.org/doc/draft-ietf-regext-org-ext/ Review? 7. RDAP jcr (Andrew Newton, 10 minutes) https://datatracker.ietf.org/doc/draft-newton-rdap-jcr/ 8. RDAP partial response and reverse search (Mario Loffredo, 20 minutes) https://datatracker.ietf.org/doc/draft-loffredo-regext-rdap-sorting-and-paging/ 9. Interim meeting feedback (5 min.) 10. AOB Working session, second hour: 1. Validate draft (Roger Carney, 20 minustes) 2. Registry Mapping and Launch Phase Listing (Roger Carney, 40 minustes) Regards, Jim and Antoin - -- Antoin Verschuren Tweevoren 6, 5672 SB Nuenen, NL M: +31 6 37682392 signature.asc Description: Message signed with OpenPGP using GPGMail ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] REGEXT Interim Meeting Invite
I will attend too. But so far the chairs seem to be the only attendants? Are there any more people that will attend? I was waiting for some more respondents before scheduling the meeting. I just submitted the official meeting request, but that would be a late notice for the secretariat. Roger, did you get any feedback on attendance? Regards, - -- Antoin Verschuren Tweevoren 6, 5672 SB Nuenen, NL M: +31 6 37682392 Op 13 dec. 2017, om 14:46 heeft James Galvin <gal...@elistx.com> het volgende geschreven: > I will attend. > > Jim > > > > On 7 Dec 2017, at 11:36, Roger D Carney wrote: > > Good Morning, > > > > I would like to invite everyone to an interim meeting Wednesday January 10th > at 19:00 UTC for 60 minutes. > > > > We plan to discuss items around the latest version of the Fee draft and to > introduce a Registry Mapping proposal. > > > > Agenda > > Fee > Discuss appropriate level for , at the object level or > level > Discuss WG Last Call > Registry Mappings > Introduce the Registry Mapping concepts > > > We will once again use Zoom as a conferencing tool, please use this link to > connect to the meeting. > > > > Please reply to the list or directly to myself if you plan on attending this > meeting. > > > > > > Thanks > > Roger > > > > ___ > regext mailing list > regext@ietf.org > https://www.ietf.org/mailman/listinfo/regext > > ___ > regext mailing list > regext@ietf.org > https://www.ietf.org/mailman/listinfo/regext signature.asc Description: Message signed with OpenPGP using GPGMail ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
[regext] Preparing for IETF 101
Dear Working group, It’s time to start planning for IETF 101 in London. We would like to hear from the working group if anyone wants to request additional work meeting time. I guess we want to meet in London, and we plan to request a 2 hour session that we will split up in a regular and a work session. Should this not be enough we can also request the ad-hoc conference room for an additional work session. Please start thinking about agenda items and let us know what you think before next friday when scheduling is due. regards, Jim and Antoin - -- Antoin Verschuren Tweevoren 6, 5672 SB Nuenen, NL M: +31 6 37682392 signature.asc Description: Message signed with OpenPGP using GPGMail ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
[regext] Call for agenda items for IETF 101
Hi all, This is an early warning to start thinking about agenda items for IETF 101. We have requested a 1,5 hour regular meeting slot, and 1 hour working session. So far, We have noted Roger to talk about fees, Registry Mapping and the Validate draft. The preliminary agenda will be posted next week, after which we will push harder ;-). Regards, Jim and Antoin - -- Antoin Verschuren Tweevoren 6, 5672 SB Nuenen, NL M: +31 6 37682392 signature.asc Description: Message signed with OpenPGP using GPGMail ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
[regext] Publication has been requested for draft-ietf-regext-org-ext-07
Antoin Verschuren has requested publication of draft-ietf-regext-org-ext-07 as Proposed Standard on behalf of the REGEXT working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-regext-org-ext/ ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] Call for adoption: draft-hollenbeck-regext-rdap-object-tag
Dear all, Sorry for the delay, but since we had no objections and 2 non-authors supporting adoption, the chairs now declare this document adopted. Scott, if you submit a new version of the document it can be renamed and we will put it in our milestones list and change the state accordingly. We have set up a pre-approvel for a draft-ietf-regext-rdap-object-tag-00 document name. Regards, Jim and Antoin - -- Antoin Verschuren Tweevoren 6, 5672 SB Nuenen, NL M: +31 6 37682392 Op 13 dec. 2017, om 14:44 heeft Antoin Verschuren <i...@antoin.nl> het volgende geschreven: > Hi all, > > As discussed in Singapore, we have cleaned up our list of action items and > moved documents along to the IESG and into working group last call, so we can > now adopt new documents. > This is a formal adoption request for draft-hollenbeck-regext-rdap-object-tag > > The draft is available here: > https://datatracker.ietf.org/doc/draft-hollenbeck-regext-rdap-object-tag/ > > Please review this draft to see if you think it is suitable for adoption by > REGEXT, and comment to the list, clearly stating your view. > Please also indicate if you are willing to contribute text, review, etc. > > This call for adoption ends 20 December 2017. > If there are no objections, and we receive enough consensus for adoption, the > chairs will consider this document adopted. > > Thanks, > > Your REGEXT co-chairs Jim and Antoin. > > - -- > Antoin Verschuren > > Tweevoren 6, 5672 SB Nuenen, NL > M: +31 6 37682392 > > > > > > signature.asc Description: Message signed with OpenPGP using GPGMail ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
[regext] IETF 101 agenda and POSSIBLE RESCEDULING
Hi All, Below is our preliminary agenda for our REGEXT IETF 101 meeting that I posted since the agenda was due. As you can see, we only received extra items from Roger, and we still have space left on our agenda. If you have any more items you wish to discuss, please let the chairs know asap! Also be AWARE of the following: We have received a request to reschedule our Wednesday 1520 regular meeting session due to a conflict of another WG. The workable options for rescheduling we were presented are Tuesday 0930 or Friday 1150. The problem of the Tuesday option is that both Adam our AD, and myself as co-chair have a conflict on Tuesday, but Jim our other co-chair hasn’t. However, we feel that the Friday might be a conflict for the WG, as the work meeting on Monday and a regular session on Friday may be too far apart. So we opted our first choice to reschedule to Tuesday, and I will sacrifice my remote presence for the benefit of the WG and I will try to follow the meeting over a low bandwidth link. We have yet to hear which of the 2 options works best for the IETF, so be aware we may still reschedule to Friday if that’s the only option left. Preliminary agenda: Registration Protocols Extensions (REGEXT) IETF 101, London, UK, Agenda Co-chairs: Jim Galvin, Antoin Verschuren Mailinglist: regext@ietf.org * Session I, Work session. Monday 2018-03-19 17:40 - 18:40 Introduce the Registry Mapping concepts (Roger Carney) This will be a discussion/work session on a new Registry mapping proposal, a new Policy document that describes all of the variable paths that an extension creates (SHOULD(s), MAY(s), lists, etc). * * Session II, Regular WG meeting session. Wednesday 2018-03-21 15:20 - 16:50 1. Welcome and Introductions (5 minutes) i. Jabber scribe ii. Notes scribe iii. NOTE WELL 2. Existing Document Status 2.a. Published (2 minutes) i. Launch Phase Mapping for the Extensible Provisioning Protocol RFC 8334 (was draft-ietf-regext-launchphase ) 2.b. Working group (past) last call documents (15 minutes) i. https://datatracker.ietf.org/doc/draft-ietf-regext-epp-fees/ (Roger Carney 10 minutes) ii. https://datatracker.ietf.org/doc/draft-ietf-regext-change-poll/ iii. https://datatracker.ietf.org/doc/draft-ietf-regext-allocation-token/ 3. https://datatracker.ietf.org/doc/draft-ietf-regext-validate/ (Roger Carney 10 minutes) 4. Working session summary (10 minutes) i. Introduce the Registry Mapping concepts (Roger Carney) 5. Milestone status review (Adoption requests, Renaming, Milestones) (20 minutes) There are some items that can be closed on our milestone list, and some recently adopted documents that need to be added but we need to discuss the priority and maturity for them. We also want to discuss new documents to adopt. (milestone list / adopted documents overview to be added) 6. AOB * Regards, Jim and Antoin - -- Antoin Verschuren Tweevoren 6, 5672 SB Nuenen, NL M: +31 6 37682392 signature.asc Description: Message signed with OpenPGP using GPGMail ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
[regext] Preliminary agenda for IETF102 Bangkok
Hi all, Please find below the preliminary agenda for Bangkok that I drafted where I hope I understood all your requests. I had several messages to work through to gather your requests. Could each of you that indicated to me they wish to be on the agenda verify that they are, and please fill in the open gaps regarding speakers or documents? If not, please reply to this message so I can track the changes. As you may see, we have a full agenda already. We need to think carefully about preparation. Jim will send a separate message to the list about how we think to handle that. Registration Protocols Extensions (REGEXT) IETF 103, Bankok, Thailand, Agenda Co-chairs: Jim Galvin, Antoin Verschuren Mailinglist: regext@ietf.org * Tuesday, November 6th, 16:10-18:10, Boromphimarn 4 1. Welcome and Introductions (4 minutes) i. Jabber scribe ii. Notes scribe iii. NOTE WELL iv. Charter update (2 min.) v. Document management 2. Existing Document Status 2.a. RFC Editor queue (2 minutes) i. Registration Data Access Protocol (RDAP) Object Tagging https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-object-tag/ ii. Allocation Token Extension for the Extensible Provisioning Protocol (EPP) https://datatracker.ietf.org/doc/draft-ietf-regext-allocation-token/ 2.b. IESG Evaluation (4 minutes) i. Change Poll Extension for the Extensible Provisioning Protocol (EPP) https://datatracker.ietf.org/doc/draft-ietf-regext-change-poll/ ii. Extensible Provisioning Protocol (EPP) Organization Mapping https://datatracker.ietf.org/doc/draft-ietf-regext-org/ Organization Extension for the Extensible Provisioning Protocol (EPP) https://datatracker.ietf.org/doc/draft-ietf-regext-org-ext/ iii.Registry Fee Extension for the Extensible Provisioning Protocol (EPP) https://datatracker.ietf.org/doc/draft-ietf-regext-epp-fees/ 2.c. Past WG last call: Waiting for shepherd writeup (3 minutes) i. Extensible Provisioning Protocol (EPP) Domain Name Mapping Extension for Strict Bundling Registration https://datatracker.ietf.org/doc/draft-ietf-regext-bundling-registration 3. HRPC Human Rights Review of draft-ietf-regext-verificationcode (15 min) 4. New candidate documents for adopting: (Max 9 min per item) i. Registration Data Access Protocol (RDAP) Reverse search capabilities (Mario Loffredo) https://datatracker.ietf.org/doc/draft-loffredo-regext-rdap-reverse-search/ ii. Registration Data Access Protocol (RDAP) Query Parameters for Result Sorting and Paging (Mario Loffredo) https://datatracker.ietf.org/doc/draft-loffredo-regext-rdap-sorting-and-paging/ iii.Login Security Policy Extensions Mapping for the Extensible Provisioning Protocol (EPP) (James Gould) https://datatracker.ietf.org/doc/draft-gould-regext-login-security-policy/ iv. Launch Phase Policy Extensions Mapping for the Extensible Provisioning Protocol (EPP) (James Gould) https://datatracker.ietf.org/doc/draft-gould-regext-launch-policy/ v. Login Security Extension for the Extensible Provisioning Protocol (EPP) (James Gould) https://datatracker.ietf.org/doc/draft-gould-regext-login-security/ vi. Extensible Provisioning Protocol (EPP) Unhandled Namespaces (James Gould) https://datatracker.ietf.org/doc/draft-gould-casanova-regext-unhandled-namespaces/ vii.Registry Reporting Repository (Who??) https://datatracker.ietf.org/doc/draft-mcpherson-sattler-registry-reporting-repo/ viii.Other Registry mapping documents (Please specify!) 5. WG Adoption discussion and Milestone review. (10 min) 6. AOB * - -- Antoin Verschuren Tweevoren 6, 5672 SB Nuenen, NL M: +31 6 37682392 ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
[regext] Publication has been requested for draft-ietf-regext-change-poll-09
Antoin Verschuren has requested publication of draft-ietf-regext-change-poll-09 as Proposed Standard on behalf of the REGEXT working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-regext-change-poll/ ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] [Ext] Re: WGLC redux: REGEXT working group charter
I personally think it does too. At least I wrote the text to include those documents in scope. But since I’m not a native english speaker it would help to know if others read that text the same way too. And confirm it’s not too broad in scope too. - -- Antoin Verschuren Tweevoren 6, 5672 SB Nuenen, NL M: +31 6 37682392 > Op 15 sep. 2018, om 03:32 heeft Gustavo Lozano het > volgende geschreven: > > I think it does, but it would be great if the chairs could confirm. > > Regards, > Gustavo > > From: regext mailto:regext-boun...@ietf.org>> On > Behalf Of Gould, James > Sent: Friday, September 14, 2018 08:57 > To: jkol...@godaddy.com <mailto:jkol...@godaddy.com>; i...@antoin.nl > <mailto:i...@antoin.nl>; regext@ietf.org <mailto:regext@ietf.org> > Subject: [Ext] Re: [regext] WGLC redux: REGEXT working group charter > > Related to bullet #2, I’m hoping that it addresses file formats such as: > > Data Escrow File Format (draft-arias-noguchi-registry-data-escrow and > draft-arias-noguchi-dnrd-objects-mapping) > a. This format is associated with data escrow deposits from > registration entities (registry, registrar, privacy and proxy services) to > data escrow providers. Can a data escrow provider be considered a > registration entity? > Data Set File Format (draft-gould-regext-dataset) > a. This format is primarily meant to be between registrar and registry; > although a 3rd party can generate a signed data set. > > — > > JG > > > > James Gould > Distinguished Engineer > jgo...@verisign.com > > 703-948-3271 > 12061 Bluemont Way > Reston, VA 20190 > > Verisign.com <http://verisigninc.com/> > > From: regext mailto:regext-boun...@ietf.org>> on > behalf of Jody Kolker mailto:jkol...@godaddy.com>> > Date: Friday, September 14, 2018 at 11:15 AM > To: Antoin Verschuren mailto:i...@antoin.nl>>, Registration > Protocols Extensions mailto:regext@ietf.org>> > Subject: [EXTERNAL] Re: [regext] WGLC redux: REGEXT working group charter > > Since EPP and RDAP is included in this paragraph: > > << > The working group may also take on work to develop specifications that > describe the following types of information exchanged between entities > involved in Internet identifier registration that are using the RDAP or > EPP protocols: > >> > > Can this paragraph be updated to: > << > *Uniform representation formats for publishing local policy or > configuration options between registration entities. > *Data formats for files exchanged between registration entities. > *Technical guidance for registration processes between registration entities. > > >> > > The reason for changing the 2nd bullet “*Data formats for files exchanged > between registration entities that > need insertion in or extraction from EPP or RDAP.” Is that the data reports > are not downloaded via EPP or RDAP. > > Thanks, > Jody Kolker > > From: regext mailto:regext-boun...@ietf.org>> On > Behalf Of Antoin Verschuren > Sent: Friday, September 7, 2018 9:20 AM > To: Registration Protocols Extensions <mailto:regext@ietf.org>> > Subject: Re: [regext] WGLC redux: REGEXT working group charter > > Alex,Patrick, > > Thank you for your comments. You made some good suggestions. > I agree the scope of the bulletpoints are not that clear and not scoped > narrow enough for people not in this working group and not knowing which > documents we discussed. > How about changing the last paragraph with bulletpoints to this: > > --- > The working group may also take on work to develop specifications that > describe the following types of information exchanged between entities > involved in Internet identifier registration that are using the RDAP or > EPP protocols: > > *Uniform representation formats for publishing local policy or > configuration options regarding EPP and RDAP use. > *Data formats for files exchanged between registration entities that > need insertion in or extraction from EPP or RDAP. > *Technical guidance for registration processes that are supported by > EPP or RDAP. > — > > To explain out thinking: > The “registry mapping” and similar documents will fall under bulletpoint 1 > The draft-gould-regext-dataset and similar documents will fall under > bulletpoint 2 > The “dnsoperator-to-rrr-protocol” and similar documents will fall under > bulletpoint 3 > > If you agree to this text, than we will change that in the version we resend > to the IESG for reconsideration. > > - -- > Antoin Verschuren > > Tweevoren 6, 5672
[regext] Agenda Items for Prague
Hi All, It is time to start thinking about IETF 104 in Prague. As always, we are asking for agenda items to predict the time slot we need. Please send your requests to the list or to the chairs. And as usual, we would also like to know if we need a separate work session to work on specific drafts. What does the working group think? There are some new drafts to be selected to be on our milestones. We have not yet finished that discussion, but be sure that when we want to discuss individual drafts in a work session, then we need the authors to lead that discussion. We would like to know before Februari 1st so we will be in time for the deadline to request one or two sessions. Let us know what you think. Jim and Antoin - -- Antoin Verschuren Tweevoren 6, 5672 SB Nuenen, NL M: +31 6 37682392 ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
[regext] Call for adoption: draft-gould-regext-login-security
Hi all, As discussed on the mailinglist, we have selected 5 documents that people most want to be added to our milestone list. To be able to to that the documents should first be adopted as working group documents. This is a formal adoption request for draft-gould-regext-login-security The draft is available here: https://datatracker.ietf.org/doc/draft-gould-regext-login-security/ Please review this draft to see if you think it is suitable for adoption by REGEXT, and comment to the list, clearly stating your view. Please also indicate if you are willing to contribute text, review, be a document shepherd, etc. This call for adoption ends 25 Januari 2019. If there are no objections, and we receive enough consensus for adoption, the chairs will consider this document adopted. Thanks, Your REGEXT co-chairs Jim and Antoin. - -- Antoin Verschuren Tweevoren 6, 5672 SB Nuenen, NL M: +31 6 37682392 ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
[regext] Call for adoption: draft-loffredo-regext-rdap-partial-response
Hi all, As discussed on the mailinglist, we have selected 5 documents that people most want to be added to our milestone list. To be able to to that the documents should first be adopted as working group documents. This is a formal adoption request for draft-loffredo-regext-rdap-partial-response The draft is available here: https://datatracker.ietf.org/doc/draft-loffredo-regext-rdap-partial-response/ Please review this draft to see if you think it is suitable for adoption by REGEXT, and comment to the list, clearly stating your view. Please also indicate if you are willing to contribute text, review, be a document shepherd, etc. This call for adoption ends 25 Januari 2019. If there are no objections, and we receive enough consensus for adoption, the chairs will consider this document adopted. Thanks, Your REGEXT co-chairs Jim and Antoin. - -- Antoin Verschuren Tweevoren 6, 5672 SB Nuenen, NL M: +31 6 37682392 ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
[regext] Call for adoption: draft-loffredo-regext-rdap-reverse-search
Hi all, As discussed on the mailinglist, we have selected 5 documents that people most want to be added to our milestone list. To be able to to that the documents should first be adopted as working group documents. This is a formal adoption request for draft-loffredo-regext-rdap-reverse-search The draft is available here: https://datatracker.ietf.org/doc/draft-loffredo-regext-rdap-reverse-search/ Please review this draft to see if you think it is suitable for adoption by REGEXT, and comment to the list, clearly stating your view. Please also indicate if you are willing to contribute text, review, be a document shepherd, etc. This call for adoption ends 25 Januari 2019. If there are no objections, and we receive enough consensus for adoption, the chairs will consider this document adopted. Thanks, Your REGEXT co-chairs Jim and Antoin. - -- Antoin Verschuren Tweevoren 6, 5672 SB Nuenen, NL M: +31 6 37682392 ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
[regext] Call for adoption: draft-hollenbeck-regext-rdap-openid
Hi all, As discussed on the mailinglist, we have selected 5 documents that people most want to be added to our milestone list. To be able to to that the documents should first be adopted as working group documents. This is a formal adoption request for draft-hollenbeck-regext-rdap-openid The draft is available here: https://datatracker.ietf.org/doc/draft-hollenbeck-regext-rdap-openid/ Please review this draft to see if you think it is suitable for adoption by REGEXT, and comment to the list, clearly stating your view. Please also indicate if you are willing to contribute text, review, be a document shepherd, etc. This call for adoption ends 25 Januari 2019. If there are no objections, and we receive enough consensus for adoption, the chairs will consider this document adopted. Thanks, Your REGEXT co-chairs Jim and Antoin. - -- Antoin Verschuren Tweevoren 6, 5672 SB Nuenen, NL M: +31 6 37682392 ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] WGLC redux: REGEXT working group charter
Op 14 sep. 2018, om 17:14 heeft Jody Kolker het volgende geschreven: > > Since EPP and RDAP is included in this paragraph: > > << > The working group may also take on work to develop specifications that > describe the following types of information exchanged between entities > involved in Internet identifier registration that are using the RDAP or > EPP protocols: > >> > > Can this paragraph be updated to: > << > *Uniform representation formats for publishing local policy or > configuration options between registration entities. > *Data formats for files exchanged between registration entities. > *Technical guidance for registration processes between registration entities. > > >> > > The reason for changing the 2nd bullet “*Data formats for files exchanged > between registration entities that > need insertion in or extraction from EPP or RDAP.” Is that the data reports > are not downloaded via EPP or RDAP. But the data is extracted from the database that is filled by EPP right? So it’s “EPP data”. True, you’ll need some imagination, and I also don’t know how to phrase that better right now, but I think that we want to prevent that f.e. invoice formats, advertising text, contracts or any other god knows what non protocol paper work between registries/registrars/registrants will be in scope as long as the entity uses some system that runs EPP or RDAP. Do you agree that that may be in scope by the text that you propose and that that would be undesirable? - -- Antoin Verschuren Tweevoren 6, 5672 SB Nuenen, NL M: +31 6 37682392 signature.asc Description: Message signed with OpenPGP ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
[regext] Preliminary agenda for Prague, and call for agenda items
Hi all, Please find the preliminary agenda for Prague attached. I hope I captured everyone that has requested time to speak. If not, let the chairs know. We still have a little bit of time left on the agenda, so if you have urgent agenda items, let us know as well. If you are on the agenda, start preparing ;-) Registration Protocols Extensions (REGEXT) IETF 104, Prague, Czech Republic, Agenda Co-chairs: Jim Galvin, Antoin Verschuren Mailinglist: regext@ietf.org * Monday, March 25th, 13:50-15:50, Berlin/Brussels 1. Welcome and Introductions (4 minutes) i. Jabber scribe ii. Notes scribe iii. NOTE WELL iv. Document management 2. Existing Document Status (10 minutes) 2.a. New RFC's (1 minute) i. Allocation Token Extension for the Extensible Provisioning Protocol (EPP) RFC 8495: https://datatracker.ietf.org/doc/rfc8495/ ii. Registration Data Access Protocol (RDAP) Object Tagging RFC 8521: https://datatracker.ietf.org/doc/rfc8521/ 2.b. RFC Editor queue (2 minutes) i. Change Poll Extension for the Extensible Provisioning Protocol (EPP) https://datatracker.ietf.org/doc/draft-ietf-regext-change-poll/ ii. Extensible Provisioning Protocol (EPP) Organization Mapping https://datatracker.ietf.org/doc/draft-ietf-regext-org/ Organization Extension for the Extensible Provisioning Protocol (EPP) https://datatracker.ietf.org/doc/draft-ietf-regext-org-ext/ 2.c. IESG evaluation (2 minutes) i. Registry Fee Extension for the Extensible Provisioning Protocol (EPP) https://datatracker.ietf.org/doc/draft-ietf-regext-epp-fees/ ii. Extensible Provisioning Protocol (EPP) Domain Name Mapping Extension for Strict Bundling Registration (Informational) https://datatracker.ietf.org/doc/draft-ietf-regext-bundling-registration 2.d. Still to do (5 minutes) i. Verification Code Extension for the Extensible Provisioning Protocol (EPP) (James Gould, 5 minutes) https://datatracker.ietf.org/doc/draft-ietf-regext-verificationcode/ Looking for reviewers! 3. Newly adopted documents (60 minutes) i. Federated Authentication for the Registration Data Access Protocol (RDAP) using OpenID Connect (Scott Hollenbeck, 20 minutes) https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-openid/ ii. Registration Data Access Protocol (RDAP) Query Parameters for Result Sorting and Paging (Mario Loffredo, 10 minutes) https://datatracker.ietf.org/doc/draft-loffredo-regext-rdap-sorting-and-paging/ iii.Registration Data Access Protocol (RDAP) Partial Response (Mario Loffredo, 10 minutes) https://datatracker.ietf.org/doc/draft-loffredo-regext-rdap-partial-response/ iv. Registration Data Access Protocol (RDAP) Reverse search capabilities (Mario Loffredo, 10 minutes) https://datatracker.ietf.org/doc/draft-loffredo-regext-rdap-reverse-search/ v. Login Security Extension for the Extensible Provisioning Protocol (EPP) (James Gould, 10 minutes) https://datatracker.ietf.org/doc/draft-gould-regext-login-security/ Looking for reviewers! 4. Milestones review. (15 minutes) With the 5 newly adopted documents just discussed, and 1 left over from our queue what should be the priority and timeline for our milestones. The chairs will send a proposal to the list before the meeting. 5. New work i. RDAP Mirroring Protocol (RMP) (Tom Harrison, 10 minutes) https://datatracker.ietf.org/doc/draft-harrison-regext-rdap-mirroring/ ii. Map a registrar ID to the registrar RDAP server URL (Marc Blanchet, 5 minutes) 6. AOB * Regards, Jim and Antoin - -- Antoin Verschuren Tweevoren 6, 5672 SB Nuenen, NL M: +31 6 37682392 ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] Preliminary agenda for Prague, and call for agenda items
We still have some time left on out agenda to spend on these topics. I will post the preliminary agenda as is if nobody steps forward to introduce or lead the discussion, and we can do it under AOB. Otherwise I will adjust the agenda to dedicate time to these agenda items. In that case we will try to reduce the time spent on item 4 and 2 as much as possible. So who is willing to lead these discussions? - -- Antoin Verschuren Tweevoren 6, 5672 SB Nuenen, NL M: +31 6 37682392 > Op 26 feb. 2019, om 01:48 heeft Andrew Newton het volgende > geschreven: > > If there are people who wish to present/discuss either the security > lock issue or the rdap jcard issue, I suggest we forgo the entirety of > item 4 and maybe even item 2 to regain 15 to 25 minutes of valuable > face-to-face time. These seem like administrative items that can be > done on the mailing list. > > -andy > > > On Sun, Feb 24, 2019 at 8:42 AM Antoin Verschuren wrote: >> >> Hi all, >> >> Please find the preliminary agenda for Prague attached. >> I hope I captured everyone that has requested time to speak. If not, let the >> chairs know. >> We still have a little bit of time left on the agenda, so if you have urgent >> agenda items, let us know as well. >> If you are on the agenda, start preparing ;-) >> >> >> >> >> >> Regards, Jim and Antoin >> >> - -- >> Antoin Verschuren >> >> Tweevoren 6, 5672 SB Nuenen, NL >> M: +31 6 37682392 >> >> >> >> >> >> >> ___ >> regext mailing list >> regext@ietf.org >> https://www.ietf.org/mailman/listinfo/regext > > ___ > regext mailing list > regext@ietf.org > https://www.ietf.org/mailman/listinfo/regext ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] Call for adoption: draft-loffredo-regext-rdap-reverse-search
[chair hat off] I didn’t want to influence this call for adoption with my personal opinion, but I do have a use case that I think is important to consider. According to the GDRP, any individual has a right to make a request to an entity that gathers data to have insight in what data is stored from him or her. This is to protect the consumers so that he knows which data he needs to control. For an entity to be able to deliver this data to an individual, it needs to do a reverse search. So, my argument here is that not being able to do a reverse search means you do not comply with GDRP guidelines….. That only the individual itself can order this reverse search to be done is policy, not technical. That’s why RDAP has the concept of federated access. To be able to comply to that sort of policies of who can do what. - -- Antoin Verschuren Tweevoren 6, 5672 SB Nuenen, NL M: +31 6 37682392 > Op 25 jan. 2019, om 17:21 heeft Niels ten Oever > het volgende geschreven: > > Hi Thomas, > > On 1/25/19 4:18 PM, Thomas Corte wrote: >> Hello Niels, >> >> On 1/25/19 15:39, Niels ten Oever wrote: >> >>> But if the IETF produces protocols which are non-GDPR compliant upon >>> implementation, and are violating human rights, that is imho not something >>> we should want. >> >> Why should the IETF, a *global* organization, restrict its protocols to >> ensure GDPR compliance, i.e. a piece of legislation only applicable in >> the *European Union* and nowhere else? >> > > I fully agree that the IETF does not need to restrict its protocols to the > legislations of one geographical area. But I think the IETF should help > implementers to not violate the human rights of end-users, and consider > regulation when implementing. The IETF can seek to do so by thoroughly > analyzing the potential impacts of the protocols that are produced in and > published by the IETF and report on the in privacy, security and human rights > considerations. > > Best, > > Niels > > PS The legislation not only applicable in the European Union, but anywhere in > the world where the data of EU citizens or residents is held. > > >> Best regards, >> >> Thomas >> > > -- > Niels ten Oever > Researcher and PhD Candidate > Datactive Research Group > University of Amsterdam > > PGP fingerprint 2458 0B70 5C4A FD8A 9488 > 643A 0ED8 3F3A 468A C8B3 > > ___ > regext mailing list > regext@ietf.org > https://www.ietf.org/mailman/listinfo/regext ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] Call for adoption: draft-loffredo-regext-rdap-sorting-and-paging
Dear WG, The call for adoption for draft-loffredo-regext-rdap-sorting-and-paging ended 25 Januari 2019. The results were: Support: 7 Object: 0 The chairs considder this draft adopted by the REGEXT WG. Request to the authors: Please submit a new version of the draft with the following name: draft-ietf-regext-rdap-sorting-and-paging-00 The chairs have already pre-approved this document so once submitted it will be automaticaly accepted as a WG document. Your co-chairs Jim and Antoin - -- Antoin Verschuren Tweevoren 6, 5672 SB Nuenen, NL M: +31 6 37682392 > Op 18 jan. 2019, om 17:04 heeft Antoin Verschuren het > volgende geschreven: > > Hi all, > > As discussed on the mailinglist, we have selected 5 documents that people > most want to be added to our milestone list. > To be able to to that the documents should first be adopted as working group > documents. > This is a formal adoption request for > draft-loffredo-regext-rdap-sorting-and-paging > > The draft is available here: > https://datatracker.ietf.org/doc/draft-loffredo-regext-rdap-sorting-and-paging/ > > Please review this draft to see if you think it is suitable for adoption by > REGEXT, and comment to the list, clearly stating your view. > Please also indicate if you are willing to contribute text, review, be a > document shepherd, etc. > > This call for adoption ends 25 Januari 2019. > If there are no objections, and we receive enough consensus for adoption, the > chairs will consider this document adopted. > > Thanks, > > Your REGEXT co-chairs Jim and Antoin. > > - -- > Antoin Verschuren > > Tweevoren 6, 5672 SB Nuenen, NL > M: +31 6 37682392 > > > > > > > ___ > regext mailing list > regext@ietf.org > https://www.ietf.org/mailman/listinfo/regext ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] Call for adoption: draft-gould-regext-login-security
Dear WG, The call for adoption for draft-gould-regext-login-security ended 25 Januari 2019. The results were: Support: 6 Object: 0 The chairs considder this draft adopted by the REGEXT WG. Request to the authors: Please submit a new version of the draft with the following name: draft-ietf-regext-login-security-00 The chairs have already pre-approved this document so once submitted it will be automaticaly accepted as a WG document. Your co-chairs Jim and Antoin - -- Antoin Verschuren Tweevoren 6, 5672 SB Nuenen, NL M: +31 6 37682392 > Op 18 jan. 2019, om 17:04 heeft Antoin Verschuren het > volgende geschreven: > > Hi all, > > As discussed on the mailinglist, we have selected 5 documents that people > most want to be added to our milestone list. > To be able to to that the documents should first be adopted as working group > documents. > This is a formal adoption request for draft-gould-regext-login-security > > The draft is available here: > https://datatracker.ietf.org/doc/draft-gould-regext-login-security/ > > Please review this draft to see if you think it is suitable for adoption by > REGEXT, and comment to the list, clearly stating your view. > Please also indicate if you are willing to contribute text, review, be a > document shepherd, etc. > > This call for adoption ends 25 Januari 2019. > If there are no objections, and we receive enough consensus for adoption, the > chairs will consider this document adopted. > > Thanks, > > Your REGEXT co-chairs Jim and Antoin. > > - -- > Antoin Verschuren > > Tweevoren 6, 5672 SB Nuenen, NL > M: +31 6 37682392 > > > > > > > ___ > regext mailing list > regext@ietf.org > https://www.ietf.org/mailman/listinfo/regext ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] Call for adoption: draft-loffredo-regext-rdap-reverse-search
Dear WG, The call for adoption for draft-loffredo-regext-rdap-reverse-search ended 25 Januari 2019. The results were: Support: 8 Object: 1 The chairs decision to adopt requires some explanation: Adopting work to our working group does not mean a draft will automatically be approved as a standards track document. There can be many results discussing a document: -A document can be submitted to the IESG for publication after thorough review -A document can be abandoned after it turns out to be a bad idea after discussion in the working group -Specific text like a privacy section can be added -etc. Seeing the lively discussion on the mailinglist means that people have an opinion, and that there is work to be done to reach consensus. It is essential that this discussion has a home for it to be open and transparent. The chairs decision is therefor to adopt this work by the REGEXT WG. Request to the authors: Please submit a new version of the draft with the following name: draft-ietf-regext-rdap-reverse-search-00 The chairs have already pre-approved this document so once submitted it will be automaticaly accepted as a WG document. Your co-chairs Jim and Antoin - -- Antoin Verschuren Tweevoren 6, 5672 SB Nuenen, NL M: +31 6 37682392 > Op 18 jan. 2019, om 17:04 heeft Antoin Verschuren het > volgende geschreven: > > Hi all, > > As discussed on the mailinglist, we have selected 5 documents that people > most want to be added to our milestone list. > To be able to to that the documents should first be adopted as working group > documents. > This is a formal adoption request for > draft-loffredo-regext-rdap-reverse-search > > The draft is available here: > https://datatracker.ietf.org/doc/draft-loffredo-regext-rdap-reverse-search/ > > Please review this draft to see if you think it is suitable for adoption by > REGEXT, and comment to the list, clearly stating your view. > Please also indicate if you are willing to contribute text, review, be a > document shepherd, etc. > > This call for adoption ends 25 Januari 2019. > If there are no objections, and we receive enough consensus for adoption, the > chairs will consider this document adopted. > > Thanks, > > Your REGEXT co-chairs Jim and Antoin. > > - -- > Antoin Verschuren > > Tweevoren 6, 5672 SB Nuenen, NL > M: +31 6 37682392 > > > > > > > ___ > regext mailing list > regext@ietf.org > https://www.ietf.org/mailman/listinfo/regext ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] Call for adoption: draft-loffredo-regext-rdap-partial-response
Dear WG, The call for adoption for draft-loffredo-regext-rdap-partial-response ended 25 Januari 2019. The results were: Support: 7 Object: 0 The chairs considder this draft adopted by the REGEXT WG. Request to the authors: Please submit a new version of the draft with the following name: draft-ietf-regext-rdap-partial-response-00 The chairs have already pre-approved this document so once submitted it will be automaticaly accepted as a WG document. Your co-chairs Jim and Antoin - -- Antoin Verschuren Tweevoren 6, 5672 SB Nuenen, NL M: +31 6 37682392 > Op 18 jan. 2019, om 17:03 heeft Antoin Verschuren het > volgende geschreven: > > Hi all, > > As discussed on the mailinglist, we have selected 5 documents that people > most want to be added to our milestone list. > To be able to to that the documents should first be adopted as working group > documents. > This is a formal adoption request for > draft-loffredo-regext-rdap-partial-response > > The draft is available here: > https://datatracker.ietf.org/doc/draft-loffredo-regext-rdap-partial-response/ > > Please review this draft to see if you think it is suitable for adoption by > REGEXT, and comment to the list, clearly stating your view. > Please also indicate if you are willing to contribute text, review, be a > document shepherd, etc. > > This call for adoption ends 25 Januari 2019. > If there are no objections, and we receive enough consensus for adoption, the > chairs will consider this document adopted. > > Thanks, > > Your REGEXT co-chairs Jim and Antoin. > > - -- > Antoin Verschuren > > Tweevoren 6, 5672 SB Nuenen, NL > M: +31 6 37682392 > > > > > > > ___ > regext mailing list > regext@ietf.org > https://www.ietf.org/mailman/listinfo/regext ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] Call for adoption: draft-hollenbeck-regext-rdap-openid
Dear WG, The call for adoption for draft-hollenbeck-regext-rdap-openid ended 25 Januari 2019. The results were: Support: 8 Object: 0 The chairs considder this draft adopted by the REGEXT WG. Request to the authors: Please submit a new version of the draft with the following name: draft-ietf-regext-rdap-openid-00 The chairs have already pre-approved this document so once submitted it will be automaticaly accepted as a WG document. Your co-chairs Jim and Antoin - -- Antoin Verschuren Tweevoren 6, 5672 SB Nuenen, NL M: +31 6 37682392 > Op 18 jan. 2019, om 17:03 heeft Antoin Verschuren het > volgende geschreven: > > Hi all, > > As discussed on the mailinglist, we have selected 5 documents that people > most want to be added to our milestone list. > To be able to to that the documents should first be adopted as working group > documents. > This is a formal adoption request for draft-hollenbeck-regext-rdap-openid > > The draft is available here: > https://datatracker.ietf.org/doc/draft-hollenbeck-regext-rdap-openid/ > > Please review this draft to see if you think it is suitable for adoption by > REGEXT, and comment to the list, clearly stating your view. > Please also indicate if you are willing to contribute text, review, be a > document shepherd, etc. > > This call for adoption ends 25 Januari 2019. > If there are no objections, and we receive enough consensus for adoption, the > chairs will consider this document adopted. > > Thanks, > > Your REGEXT co-chairs Jim and Antoin. > > - -- > Antoin Verschuren > > Tweevoren 6, 5672 SB Nuenen, NL > M: +31 6 37682392 > > > > > > > ___ > regext mailing list > regext@ietf.org > https://www.ietf.org/mailman/listinfo/regext ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] Secdir last call review of draft-ietf-regext-bundling-registration-09
Op 15 mrt. 2019, om 02:47 heeft Jiankang Yao het volgende geschreven: > > > Thanks for your kind review. > > < Summary: Has Issues > < Major Concerns: > < If this document is going to be published on the IETF Stream, > then the > < IANA registrations should point to the IESG, not the document > authors. > > We will update it. IANA registrations will point to the IESG. I think there is a slight misunderstanding here about the document status and IANA registration. The EPP extension registry has 2 types of registrations: (see https://datatracker.ietf.org/doc/rfc7451/ <https://datatracker.ietf.org/doc/rfc7451/>) 1. EPP standard track registrations: These extensions have had thorough review and have consensus that these are standard extensions. These EPP extensions will point to the IESG in the IANA registry (RFC 7451 section 2.2.1) 2. Proprietary EPP extensions Extensions that seek registration in the IANA EPP extensions registry, but are only supported by one or few registries. These extensions should be documented and one way of documenting them is to write an informational RFC describing how the proprietary extension works. These EPP extensions will have the Registrant information in the IANA registry, which is NOT the IESG! draft-ietf-regext-bundling-registration is of type 2 since the REGEXT WG could not reach consensus that this extension should become the standard way of bundling. Hence the informational status of the document and the Registrant should be in the IANA registration as mandated bij RFC 7451. - -- Antoin Verschuren Tweevoren 6, 5672 SB Nuenen, NL M: +31 6 37682392 ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
[regext] Call for agenda items for IETF 105
This is a request for agenda items for IETF 105 in Montreal. If you have any agenda items please send them to the list. As you may have seen, we have published a new milestone list. The order of agenda items will follow that list. The chairs want to remind the working group that we have a milestone date for one document in July. If you need to focus, then focus on reviewing that document (https://datatracker.ietf.org/doc/draft-ietf-regext-login-security/) We have a 2 hour slot, so we should have enough time for additional presentations, but let’s do the work first. Regards, Jim and Antoin - -- Antoin Verschuren Tweevoren 6, 5672 SB Nuenen, NL M: +31 6 37682392 > Op 7 jun. 2019, om 15:13 heeft IETF Meeting Session Request Tool > het volgende geschreven: > > > > A new meeting session request has just been submitted by James Galvin, a > Chair of the regext working group. > > > - > Working Group Name: Registration Protocols Extensions > Area Name: Applications and Real-Time Area > Session Requester: James Galvin > > Number of Sessions: 1 > Length of Session(s): 2 Hours > Number of Attendees: 50 > Conflicts to Avoid: > First Priority: dnssd dnsop dprive > Second Priority: saag oauth doh > > > > People who must be present: > James Galvin > Barry Leiba > Antoin Verschuren > > Resources Requested: > > Special Requests: > Please avoid any DNS related BOFs. > > - > > ___ > regext mailing list > regext@ietf.org > https://www.ietf.org/mailman/listinfo/regext ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
[regext] draft-ietf-regext-login-security
Dear Working Group, We believe the draft draft-ietf-regext-login-security still has an open issue from Patrick Meczek where James response should be confirmed, but other than that the authors indicate they did not receive any more feedback, both negative, but also not positive. Since this draft is due for July, so before the IETF 105, we would like to stress that before we can issue a last call, we would very much like to know if this draft has had enough review. If it has, than we can issue a last call before IETF 105 So, Who reviewed the document and had no issues left? - -- Antoin Verschuren Tweevoren 6, 5672 SB Nuenen, NL M: +31 6 37682392 > Op 14 jun. 2019, om 16:05 heeft Gould, James het > volgende geschreven: > > Antoin, > > There are no known open items remaining with > draft-ietf-regext-login-security, so I encourage the WG to review it and > provide feedback for discussion. > > Thanks, > > — > > JG > > > > James Gould > Distinguished Engineer > jgo...@verisign.com > > 703-948-3271 > 12061 Bluemont Way > Reston, VA 20190 > > Verisign.com <http://verisigninc.com/> > > From: regext on behalf of Antoin Verschuren > > Date: Friday, June 14, 2019 at 9:31 AM > To: regext > Subject: [EXTERNAL] [regext] Call for agenda items for IETF 105 > > This is a request for agenda items for IETF 105 in Montreal. > If you have any agenda items please send them to the list. > > As you may have seen, we have published a new milestone list. > The order of agenda items will follow that list. > The chairs want to remind the working group that we have a milestone date for > one document in July. > If you need to focus, then focus on reviewing that document > (https://datatracker.ietf.org/doc/draft-ietf-regext-login-security/ > <https://datatracker.ietf.org/doc/draft-ietf-regext-login-security/>) > > We have a 2 hour slot, so we should have enough time for additional > presentations, but let’s do the work first. > > Regards, > > Jim and Antoin > > - -- > Antoin Verschuren > > Tweevoren 6, 5672 SB Nuenen, NL > M: +31 6 37682392 > > > > > > > >> Op 7 jun. 2019, om 15:13 heeft IETF Meeting Session Request Tool >> mailto:session-requ...@ietf.org>> het volgende >> geschreven: >> >> >> >> A new meeting session request has just been submitted by James Galvin, a >> Chair of the regext working group. >> >> >> - >> Working Group Name: Registration Protocols Extensions >> Area Name: Applications and Real-Time Area >> Session Requester: James Galvin >> >> Number of Sessions: 1 >> Length of Session(s): 2 Hours >> Number of Attendees: 50 >> Conflicts to Avoid: >> First Priority: dnssd dnsop dprive >> Second Priority: saag oauth doh >> >> >> >> People who must be present: >> James Galvin >> Barry Leiba >> Antoin Verschuren >> >> Resources Requested: >> >> Special Requests: >> Please avoid any DNS related BOFs. >> >> - >> >> ___ >> regext mailing list >> regext@ietf.org <mailto:regext@ietf.org> >> https://www.ietf.org/mailman/listinfo/regext ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
[regext] Milestones update
Hi all, As we have discussed during IETF 104 in Prague, we will update our milestones. Before we add the newly adopted documents to the milestones, we first need to clean up the current milestone list. We have decided to delete the current 2 open items from the milestone list: -Submit for publication "Validate Mapping for the Extensible Provisioning Protocol” -Submit for publication an informational RFC with requirements for a registration protocol for third-party DNS providers Formally these documents will remain adopted WG documents, but they will no longer be prioritised WG work items. If anyone objects to this decision, then please send a message to the list before May 2nd so we can update the milestone list next week. Regards, Jim and Antoin - -- Antoin Verschuren Tweevoren 6, 5672 SB Nuenen, NL M: +31 6 37682392 ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
[regext] Call for agenda items for IETF 106 Singapore
Hi All, It is time to start preparing for IETF 106 in Singapore. This is a first call for agenda items so that we can judge what kind of time slot we need. But the IETF also has a new feature for agenda requests: For the first time, attendees can give up personal conflicts with other WG’s they want to attend where they are a key speaker or participant. So if you have any specific conflicts with other WG’s, please reply to this message, and list the WG’s that you need to attend. Please reply before September 27th so we have time to schedule. Regards, Jim and Antoin - -- Antoin Verschuren Tweevoren 6, 5672 SB Nuenen, NL M: +31 6 37682392 ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] New-AD review of draft-ietf-regext-bundling-registration-09
Yes Barry, I agree. Not everybody understands the background why it is an informational document and what it’s purpose is. - -- Antoin Verschuren Tweevoren 6, 5672 SB Nuenen, NL M: +31 6 37682392 > Op 27 sep. 2019, om 17:29 heeft Barry Leiba het > volgende geschreven: > > Thanks, Antoin; I agree with your analysis, and I agree that the > contact info is fine as it is, given that. > > But this is also why I think it's important for the document to > clearly say that this is documenting a proprietary extension, and that > that is why it's Informational. Without that being clear, we're going > to get pushback from the IESG about a few things. So let's be very > clear about it. Makes sense? > > Barry > > On Fri, Sep 27, 2019 at 11:13 AM Antoin Verschuren wrote: >> >> Barry, >> >> I have not reviewed all the comments yet, but I am only responing to this >> one: >> >> The SecDir review suggested changing the contact for the IANA registrations >> to the IETF, rather than the authors, and I agree: it should be “the IETF”, >> probably with the regext mailing list as the contact information. You did >> not make any change. Please do. >> >> >> This is incorrect according to RFC4741, and I have replied to the SecDir >> review on the list that it is as well. >> Section 2.2.1. of RFC4741 states: >> >> Registrant Name and Email Address: The name and email address of the >> person that is responsible for managing the registry entry. If the >> registration is of an IETF Standards Track document, this can simply >> be listed as "IESG, ”. >> >> >> draft-ietf-regext-bundling-registration is NOT an IETF Standard Track >> document. >> draft-ietf-regext-bundling-registration is an IETF INFORMATIONAL document, >> and it is for a reason. >> The REGEXT working group did not consent that this draft produces a >> standard, and therefor refused Standards track stream. >> The REGEXT working group did allow the authors to document their proprietary >> EPP extension in an informational IETF document, and adopted the document to >> help review. >> This informational document only documents a proprietary EPP extension. >> >> Proprietary EPP extensions are allowed in the IANA EPP Extensions registry, >> with an informational RFC as one type of documentation, but they are >> registered in the IANA registry with the name and email address of the one >> that registers the proprietary extension, which is the authors and NOT the >> IESG. Only Standard track documents are listed with the IESG as contact in >> the IANA EPP extensions registry. >> The purpose of the IANA EPP extensions registry is to eventually consolidate >> all proprietary extensions to standards and the registered contact is one of >> the recognition points if an EPP extension is a standard. >> We do not want proprietary EPP extensions to become standards without >> consent of the REGEXT working group. >> >> I can understand that this can be confusing for the IESG, since they mostly >> review standards track documents as output from the REGEXT working group, >> but this is one of the few exceptions that is deliberately an informational >> document. >> >> - -- >> Antoin Verschuren >> >> Tweevoren 6, 5672 SB Nuenen, NL >> M: +31 6 37682392 >> >> >> >> >> >> >> Op 26 sep. 2019, om 06:17 heeft Barry Leiba het >> volgende geschreven: >> >> This remains quite incomplete: the last call comments have not been properly >> handled. >> >> In Sections 6.1, 6.2, 7.1.2, and all the 7.2.x you made changes in response >> to Adam’s AD review, but you tried to use the second of his suggested fixes. >> What you did do is flawed, as you have introduced a space character between >> the two U+ characters (which is why he advised against that fix, because >> doing it without the extra space makes it hard to read, but adding the space >> makes it wrong). Please fix that. I suggest using Adam’s XML-escaping >> example to fix it. >> >> The Gen-ART review asked for BCP 14 key words in Section 5, and you said you >> would add them. You did not. That’s fine if you ultimately decided not to >> (I personally think it is not necessary), but I want to make sure you didn’t >> simply forget to make that change. >> >> The Gen-ART review asked for a brief explanation of what the conditions >> might be for not complying with the “SHOULD” requirements in Sections 7.2.x, >> and what the c
Re: [regext] New-AD review of draft-ietf-regext-bundling-registration-09
> This is incorrect according to RFC4741, and I have replied to the SecDir > review on the list that it is as well. > Section 2.2.1. of RFC4741 states: This should be RFC 7451 of course. Don’t know where that cut and paste went wrong ;-) - -- Antoin Verschuren Tweevoren 6, 5672 SB Nuenen, NL M: +31 6 37682392 > Op 27 sep. 2019, om 17:13 heeft Antoin Verschuren het > volgende geschreven: > > Barry, > > I have not reviewed all the comments yet, but I am only responing to this one: > >> The SecDir review suggested changing the contact for the IANA registrations >> to the IETF, rather than the authors, and I agree: it should be “the IETF”, >> probably with the regext mailing list as the contact information. You did >> not make any change. Please do. > > This is incorrect according to RFC4741, and I have replied to the SecDir > review on the list that it is as well. > Section 2.2.1. of RFC4741 states: > > Registrant Name and Email Address: The name and email address of the >person that is responsible for managing the registry entry. If the >registration is of an IETF Standards Track document, this can simply >be listed as "IESG, mailto:i...@ietf.org>>”. > > draft-ietf-regext-bundling-registration is NOT an IETF Standard Track > document. > draft-ietf-regext-bundling-registration is an IETF INFORMATIONAL document, > and it is for a reason. > The REGEXT working group did not consent that this draft produces a standard, > and therefor refused Standards track stream. > The REGEXT working group did allow the authors to document their proprietary > EPP extension in an informational IETF document, and adopted the document to > help review. > This informational document only documents a proprietary EPP extension. > > Proprietary EPP extensions are allowed in the IANA EPP Extensions registry, > with an informational RFC as one type of documentation, but they are > registered in the IANA registry with the name and email address of the one > that registers the proprietary extension, which is the authors and NOT the > IESG. Only Standard track documents are listed with the IESG as contact in > the IANA EPP extensions registry. > The purpose of the IANA EPP extensions registry is to eventually consolidate > all proprietary extensions to standards and the registered contact is one of > the recognition points if an EPP extension is a standard. > We do not want proprietary EPP extensions to become standards without consent > of the REGEXT working group. > > I can understand that this can be confusing for the IESG, since they mostly > review standards track documents as output from the REGEXT working group, but > this is one of the few exceptions that is deliberately an informational > document. > > - -- > Antoin Verschuren > > Tweevoren 6, 5672 SB Nuenen, NL > M: +31 6 37682392 > > > > > > >> Op 26 sep. 2019, om 06:17 heeft Barry Leiba > <mailto:barryle...@computer.org>> het volgende geschreven: >> >> This remains quite incomplete: the last call comments have not been properly >> handled. >> >> In Sections 6.1, 6.2, 7.1.2, and all the 7.2.x you made changes in response >> to Adam’s AD review, but you tried to use the second of his suggested fixes. >> What you did do is flawed, as you have introduced a space character between >> the two U+ characters (which is why he advised against that fix, because >> doing it without the extra space makes it hard to read, but adding the space >> makes it wrong). Please fix that. I suggest using Adam’s XML-escaping >> example to fix it. >> >> The Gen-ART review asked for BCP 14 key words in Section 5, and you said you >> would add them. You did not. That’s fine if you ultimately decided not to >> (I personally think it is not necessary), but I want to make sure you didn’t >> simply forget to make that change. >> >> The Gen-ART review asked for a brief explanation of what the conditions >> might be for not complying with the “SHOULD” requirements in Sections 7.2.x, >> and what the consequences would be. You did not add that, and I think it’s >> necessary. Please add an explanation in each of those sections. >> >> The SecDir review suggested changing the contact for the IANA registrations >> to the IETF, rather than the authors, and I agree: it should be “the IETF”, >> probably with the regext mailing list as the contact information. You did >> not make any change. Please do. >> >> You also did not address my comment about needing an explanation for why >> this is Informational and not Propo
Re: [regext] New-AD review of draft-ietf-regext-bundling-registration-09
Barry, I have not reviewed all the comments yet, but I am only responing to this one: > The SecDir review suggested changing the contact for the IANA registrations > to the IETF, rather than the authors, and I agree: it should be “the IETF”, > probably with the regext mailing list as the contact information. You did > not make any change. Please do. This is incorrect according to RFC4741, and I have replied to the SecDir review on the list that it is as well. Section 2.2.1. of RFC4741 states: Registrant Name and Email Address: The name and email address of the person that is responsible for managing the registry entry. If the registration is of an IETF Standards Track document, this can simply be listed as "IESG, ”. draft-ietf-regext-bundling-registration is NOT an IETF Standard Track document. draft-ietf-regext-bundling-registration is an IETF INFORMATIONAL document, and it is for a reason. The REGEXT working group did not consent that this draft produces a standard, and therefor refused Standards track stream. The REGEXT working group did allow the authors to document their proprietary EPP extension in an informational IETF document, and adopted the document to help review. This informational document only documents a proprietary EPP extension. Proprietary EPP extensions are allowed in the IANA EPP Extensions registry, with an informational RFC as one type of documentation, but they are registered in the IANA registry with the name and email address of the one that registers the proprietary extension, which is the authors and NOT the IESG. Only Standard track documents are listed with the IESG as contact in the IANA EPP extensions registry. The purpose of the IANA EPP extensions registry is to eventually consolidate all proprietary extensions to standards and the registered contact is one of the recognition points if an EPP extension is a standard. We do not want proprietary EPP extensions to become standards without consent of the REGEXT working group. I can understand that this can be confusing for the IESG, since they mostly review standards track documents as output from the REGEXT working group, but this is one of the few exceptions that is deliberately an informational document. - -- Antoin Verschuren Tweevoren 6, 5672 SB Nuenen, NL M: +31 6 37682392 > Op 26 sep. 2019, om 06:17 heeft Barry Leiba het > volgende geschreven: > > This remains quite incomplete: the last call comments have not been properly > handled. > > In Sections 6.1, 6.2, 7.1.2, and all the 7.2.x you made changes in response > to Adam’s AD review, but you tried to use the second of his suggested fixes. > What you did do is flawed, as you have introduced a space character between > the two U+ characters (which is why he advised against that fix, because > doing it without the extra space makes it hard to read, but adding the space > makes it wrong). Please fix that. I suggest using Adam’s XML-escaping > example to fix it. > > The Gen-ART review asked for BCP 14 key words in Section 5, and you said you > would add them. You did not. That’s fine if you ultimately decided not to > (I personally think it is not necessary), but I want to make sure you didn’t > simply forget to make that change. > > The Gen-ART review asked for a brief explanation of what the conditions might > be for not complying with the “SHOULD” requirements in Sections 7.2.x, and > what the consequences would be. You did not add that, and I think it’s > necessary. Please add an explanation in each of those sections. > > The SecDir review suggested changing the contact for the IANA registrations > to the IETF, rather than the authors, and I agree: it should be “the IETF”, > probably with the regext mailing list as the contact information. You did > not make any change. Please do. > > You also did not address my comment about needing an explanation for why this > is Informational and not Proposed Standard. It’s fine for it to be > Informational, but the shepherd writeup needs to explain why (please update > it), and the Introduction probably should also, assuming that reason has to > do with the deployment, applicability, or maturity of what’s documented here. > > I won’t pass this up to the IESG until all these points are addressed. So > back into Revised I-D needed this goes, and please handle this without undue > delay. > > Thanks, > Barry > > On Sat, Sep 21, 2019 at 7:15 AM Jiankang Yao <mailto:ya...@cnnic.cn>> wrote: > Dear Barry, > > The new version has been submitted. It addresses the comments received > during IETF LC. > > https://datatracker.ietf.org/doc/html/draft-ietf-regext-bundling-registration-10 > > <https://datatracker.ietf.org/doc/html/draft-ietf-regext-bundlin
Re: [regext] 2nd WG LAST CALL: draft-ietf-regext-dnrd-objects-mapping-01
Reminder. We need support for this 2nd WGLC too folks. So can the respondents of the first WGLC confirm nothing essential has changed? - -- Antoin Verschuren Tweevoren 6, 5672 SB Nuenen, NL M: +31 6 37682392 > Op 26 okt. 2019, om 12:19 heeft Antoin Verschuren het > volgende geschreven: > > During WGLC, the authors of draft-ietf-regext-dnrd-objects-mapping found > interoperability issues and had to produce a new version of the document. The > authors think the changes are not substantive, but there are enough changes > to justify a 2nd WGLC. > > You can find the document here: > https://datatracker.ietf.org/doc/draft-ietf-regext-dnrd-objects-mapping/ > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-regext-dnrd-objects-mapping-02 > > This 2nd WG LAST CALL will end in two weeks at close of business, Friday, 8 > November 2019. > > Please review these documents and indicate your support (a simple “+1” is > sufficient) or concerns with the publication of this document by replying to > this message on the list. > > > Regards, > > Jim and Antoin > > - -- > Antoin Verschuren > > Tweevoren 6, 5672 SB Nuenen, NL > M: +31 6 37682392 > > > > > > > ___ > regext mailing list > regext@ietf.org > https://www.ietf.org/mailman/listinfo/regext ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] 2nd WG LAST CALL: draft-ietf-regext-dnrd-objects-mapping-01
Folks, We did not receive any response to this second WGLC. This means we cannot submit this document for publication. We will extend this second WGLC with 2 weeks, ending November 22nd. Please respond with +1 if you want this document published gents! Jim and Antoin - -- Antoin Verschuren Tweevoren 6, 5672 SB Nuenen, NL M: +31 6 37682392 > Op 3 nov. 2019, om 18:47 heeft Antoin Verschuren het > volgende geschreven: > > Reminder. > > We need support for this 2nd WGLC too folks. > So can the respondents of the first WGLC confirm nothing essential has > changed? > > - -- > Antoin Verschuren > > Tweevoren 6, 5672 SB Nuenen, NL > M: +31 6 37682392 > > > > > > >> Op 26 okt. 2019, om 12:19 heeft Antoin Verschuren > <mailto:i...@antoin.nl>> het volgende geschreven: >> >> During WGLC, the authors of draft-ietf-regext-dnrd-objects-mapping found >> interoperability issues and had to produce a new version of the document. >> The authors think the changes are not substantive, but there are enough >> changes to justify a 2nd WGLC. >> >> You can find the document here: >> https://datatracker.ietf.org/doc/draft-ietf-regext-dnrd-objects-mapping/ >> <https://datatracker.ietf.org/doc/draft-ietf-regext-dnrd-objects-mapping/> >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-regext-dnrd-objects-mapping-02 >> >> This 2nd WG LAST CALL will end in two weeks at close of business, Friday, 8 >> November 2019. >> >> Please review these documents and indicate your support (a simple “+1” is >> sufficient) or concerns with the publication of this document by replying to >> this message on the list. >> >> >> Regards, >> >> Jim and Antoin >> >> - -- >> Antoin Verschuren >> >> Tweevoren 6, 5672 SB Nuenen, NL >> M: +31 6 37682392 >> >> >> >> >> >> >> ___ >> regext mailing list >> regext@ietf.org >> https://www.ietf.org/mailman/listinfo/regext > > ___ > regext mailing list > regext@ietf.org > https://www.ietf.org/mailman/listinfo/regext ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] Call for agenda items for IETF 106 Singapore
Hi all, This is a second call for agenda items for our meeting at the IETF 106 in Singapore. We have 2 hours to fill, so we expect at least the current milestone authors to have an update. We will also have updates from our Interim meeting, and discussion on a new milestone list. Singapore is in less than 4 weeks! Please reply to the list or to the chairs if you want to be on the agenda that is due in 2 weeks. - -- Antoin Verschuren Tweevoren 6, 5672 SB Nuenen, NL M: +31 6 37682392 > Op 13 sep. 2019, om 15:30 heeft Antoin Verschuren het > volgende geschreven: > > Hi All, > > It is time to start preparing for IETF 106 in Singapore. > This is a first call for agenda items so that we can judge what kind of time > slot we need. > > But the IETF also has a new feature for agenda requests: > For the first time, attendees can give up personal conflicts with other WG’s > they want to attend where they are a key speaker or participant. > So if you have any specific conflicts with other WG’s, please reply to this > message, and list the WG’s that you need to attend. > > Please reply before September 27th so we have time to schedule. > > Regards, > > Jim and Antoin > > - -- > Antoin Verschuren > > Tweevoren 6, 5672 SB Nuenen, NL > M: +31 6 37682392 > > > > > > > ___ > regext mailing list > regext@ietf.org > https://www.ietf.org/mailman/listinfo/regext ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
[regext] 2nd WG LAST CALL: draft-ietf-regext-dnrd-objects-mapping-01
During WGLC, the authors of draft-ietf-regext-dnrd-objects-mapping found interoperability issues and had to produce a new version of the document. The authors think the changes are not substantive, but there are enough changes to justify a 2nd WGLC. You can find the document here: https://datatracker.ietf.org/doc/draft-ietf-regext-dnrd-objects-mapping/ A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-regext-dnrd-objects-mapping-02 This 2nd WG LAST CALL will end in two weeks at close of business, Friday, 8 November 2019. Please review these documents and indicate your support (a simple “+1” is sufficient) or concerns with the publication of this document by replying to this message on the list. Regards, Jim and Antoin - -- Antoin Verschuren Tweevoren 6, 5672 SB Nuenen, NL M: +31 6 37682392 ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
[regext] WG LAST CALL: draft-ietf-regext-rdap-sorting-and-paging
The following working group document is believed to be ready for submission to the IESG for publication as a standards track document: https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-sorting-and-paging/ This WG last call will end at close of business, Friday, 13 March 2020. Please review this document and indicate your support (a simple “+1” is sufficient) or concerns with the publication of this document by replying to this message on the list. The authors are still looking for a document shepherd for this document. Being a document shepherd is an awesome opportunity to get involved in the IETF process. No deep inside technical review is needed, but it is a process review that needs to be done by an individual not being one of the authors. So please volunteer by replying to this message if you want this document to move forward after WGLC. The author’s will thank you for it. Regards, Jim and Antoin ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
[regext] WG LAST CALL: draft-ietf-regext-rdap-partial-response
The following working group document is believed to be ready for submission to the IESG for publication as a standards track document: https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-partial-response/ This WG last call will end at close of business, Friday, 13 March 2020. Please review this document and indicate your support (a simple “+1” is sufficient) or concerns with the publication of this document by replying to this message on the list. The authors are still looking for a document shepherd for this document. Being a document shepherd is an awesome opportunity to get involved in the IETF process. No deep inside technical review is needed, but it is a process review that needs to be done by an individual not being one of the authors. So please volunteer by replying to this message if you want this document to move forward after WGLC. The author’s will thank you for it. Regards, Jim and Antoin ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
[regext] Call for agenda items for IETF 107 Vancouver
Dear WG, IETF 107 is approaching, so it is time to set up our agenda. This is a request to send the chairs any items you wish to discuss in Vancouver. Please be aware that we will have a 2 hour meeting slot on the Friday morning in Vancouver. Remote participation and presentation will be available for those that cannot make it to Vancouver. So far on the agenda, we have our usual WG documents status review, and 2 requests for presentations: -Scott Hollenbeck on 7482bis and 7483bis -James Gould on draft-gould-regext-secure-authinfo-transfer The chairs would like the authors of the other newly adopted documents to also give a short introduction of their document and work. We have time left for other presentations on related work. Please send the chairs a request for time on the agenda, or simply reply to this message. The preliminary agenda is due next Wednesday 11-03-2020. Regards, Jim and Antoin ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] WG LAST CALL: draft-ietf-regext-tmch-func-spec
This WGLC ended last week. Gustavo: Before we can declare consensus and send this document to the IESG, the chairs believe that the comments made by Roger and Scott should be attended to in a new version of the document. Do you agree? Could you please respond to the comments made by Roger and Scott and make sure their comments are addressed? Regards, Jim and Antoin > Op 14 feb. 2020, om 16:01 heeft Antoin Verschuren het > volgende geschreven: > > The following working group document is believed to be ready for submission > to the IESG for publication as an Informational document: > > https://datatracker.ietf.org/doc/draft-ietf-regext-tmch-func-spec/ > > This WG last call will end at close of business, Friday, 28 February 2020. > > Please review this document and indicate your support (a simple “+1” is > sufficient) or concerns with the publication of this document by replying to > this message on the list. > > The document shepherd for this document is Ulrich Wisser. > > Thanks! > > Jim and Antoin > ___ > regext mailing list > regext@ietf.org > https://www.ietf.org/mailman/listinfo/regext ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
[regext] CALL FOR ADOPTION: draft-gould-regext-secure-authinfo-transfer
This is a formal adoption request for Extensible Provisioning Protocol (EPP) Secure Authorization Information for Transfer: https://datatracker.ietf.org/doc/draft-gould-regext-secure-authinfo-transfer/ Please review this draft to see if you think it is suitable for adoption by REGEXT, and comment to the list, clearly stating your view. Please also indicate if you are willing to contribute text, review text, or be a document shepherd. This call for adoption ends Friday, 7 February 2020. If there are no objections, and we receive enough consensus for adoption, the chairs will consider this document adopted. Thanks, Your REGEXT co-chairs Jim and Antoin - -- Antoin Verschuren Tweevoren 6, 5672 SB Nuenen, NL M: +31 6 37682392 ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
[regext] CALL FOR ADOPTION: draft-gould-casanova-regext-unhandled-namespaces
This is a formal adoption request for Extensible Provisioning Protocol (EPP) Unhandled Namespaces: https://datatracker.ietf.org/doc/draft-gould-casanova-regext-unhandled-namespaces/ Please review this draft to see if you think it is suitable for adoption by REGEXT, and comment to the list, clearly stating your view. Please also indicate if you are willing to contribute text, review text, or be a document shepherd. This call for adoption ends Friday, 7 February 2020. If there are no objections, and we receive enough consensus for adoption, the chairs will consider this document adopted. Thanks, Your REGEXT co-chairs Jim and Antoin ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
[regext] CALL FOR ADOPTION: draft-sattler-epp-registry-maintenance
This is a formal adoption request for Registry Maintenance Notifications for the Extensible Provisioning Protocol (EPP): https://datatracker.ietf.org/doc/draft-sattler-epp-registry-maintenance/ Please review this draft to see if you think it is suitable for adoption by REGEXT, and comment to the list, clearly stating your view. Please also indicate if you are willing to contribute text, review text, or be a document shepherd. This call for adoption ends Friday, 7 February 2020. If there are no objections, and we receive enough consensus for adoption, the chairs will consider this document adopted. Thanks, Your REGEXT co-chairs Jim and Antoin ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] New Version Notification for draft-gould-regext-secure-authinfo-transfer-03
Mario, in this scenario, "the registry" may perform the action, but not in it’s role as registry, but as a registrar of last resort. It is quite common and good practice for ccTLD’s to have a registrar of last resort implemented as an entity they run themselves or outsource where they don’t fall under ICANN’s umbrella of mandated policy, but you have to realise that you will supply the Authinfo code in a role as registrar of last resort and not as the registry function. When a registrar goes out of business, the registrar of last resort takes over the customers temporarily depending on the registry’s policy, until the registrants have found a new registrar to represent them at the registry. - -- Antoin Verschuren Tweevoren 6, 5672 SB Nuenen, NL M: +31 6 37682392 > Op 21 jan. 2020, om 14:51 heeft Mario Loffredo > het volgende geschreven: > > Hi James, > > I don't know if it also goes for other registrires but at .it the losing > registrar might be temporarily (e.g. due to a suspension) or permanently > (e.g. because the registrar goes out of business) inactive. Consequently, it > might be supposedly unable to generate the Secure AuthInfo. In this case, > the registry could generate the Secure Authinfo on request of the registrant. > > Should the secure transfer model consider such scenario too? > > Mario > > > > Il 14/01/2020 17:33, Gould, James ha scritto: > >> The draft-gould-regext-secure-authinfo-transfer-03 was posted that includes >> the following: >> >> 1. Updates based on the feedback from the interim REGEXT meeting held >> at ICANN-66 >> 2. Updates based on the review by Michael Bauland >> 3. Updates based on the authorization information messages by Martin >> Casanova on the REGEXT mailing list >> >> URL: >> https://www.ietf.org/internet-drafts/draft-gould-regext-secure-authinfo-transfer-03.txt >> >> <https://www.ietf.org/internet-drafts/draft-gould-regext-secure-authinfo-transfer-03.txt> >> Status: >> https://datatracker.ietf.org/doc/draft-gould-regext-secure-authinfo-transfer/ >> >> <https://datatracker.ietf.org/doc/draft-gould-regext-secure-authinfo-transfer/> >>Htmlized: >> https://tools.ietf.org/html/draft-gould-regext-secure-authinfo-transfer-03 >> <https://tools.ietf.org/html/draft-gould-regext-secure-authinfo-transfer-03> >> Htmlized: >> https://datatracker.ietf.org/doc/html/draft-gould-regext-secure-authinfo-transfer >> >> <https://datatracker.ietf.org/doc/html/draft-gould-regext-secure-authinfo-transfer> >> Diff: >> https://www.ietf.org/rfcdiff?url2=draft-gould-regext-secure-authinfo-transfer-03 >> >> <https://www.ietf.org/rfcdiff?url2=draft-gould-regext-secure-authinfo-transfer-03> >> >> Review and feedback is appreciated. >> >> Thanks, >> >> -- >> >> JG >> >> James Gould >> Distinguished Engineer >> jgo...@verisign.com <mailto:jgo...@verisign.com> >> >> 703-948-3271 >> 12061 Bluemont Way >> Reston, VA 20190 >> >> Verisign.com <http://verisigninc.com/> <http://verisigninc.com/> >> >> >> >> >> ___ >> regext mailing list >> regext@ietf.org <mailto:regext@ietf.org> >> https://www.ietf.org/mailman/listinfo/regext >> <https://www.ietf.org/mailman/listinfo/regext> > -- > Dr. Mario Loffredo > Servizi Internet e Sviluppo Tecnologico > CNR - Istituto di Informatica e Telematica > via G. Moruzzi 1, I-56124 PISA, Italy > E-Mail: mario.loffr...@iit.cnr.it <mailto:mario.loffr...@iit.cnr.it> > Phone: +39.0503153497 > Mobile: +39.3462122240 > Web: http://www.iit.cnr.it/mario.loffredo > <http://www.iit.cnr.it/mario.loffredo>___ > regext mailing list > regext@ietf.org <mailto:regext@ietf.org> > https://www.ietf.org/mailman/listinfo/regext > <https://www.ietf.org/mailman/listinfo/regext> ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] CALL FOR ADOPTION: draft-sattler-epp-registry-maintenance
This call for adoption has ended with no objections. The chairs therefor accepted this document as a Working Group Document. For the WG: We still need a volunteer for this document to be the document shepherd. This is an excellent opportunity to get to know the IETF processes for new working group members, so please volunteer! No real technical insight about this draft is needed to volunteer, so don’t be shy. The only thing that you will need to do is to verify that all comments during WGLC and IESG review are attended to once the document reaches that state, and fill in a template about that process. This and all other things the chairs will help you with, but we need an independent document shepherd to state that the correct process was followed. For the authors: Please resubmit the latest version of your draft with the following name: draft-ietf-regext-epp-registry-maintenance We have pre-approved the publication of this draft as a WG document. Regards, Jim and Antoin > Op 8 feb. 2020, om 05:53 heeft Joseph Yee het volgende > geschreven: > > +1 > > -Joseph > > On Fri, Jan 24, 2020 at 9:51 AM Antoin Verschuren <mailto:i...@antoin..nl>> wrote: > This is a formal adoption request for Registry Maintenance Notifications for > the Extensible Provisioning Protocol (EPP): > https://datatracker.ietf.org/doc/draft-sattler-epp-registry-maintenance/ > <https://datatracker.ietf.org/doc/draft-sattler-epp-registry-maintenance/> > > Please review this draft to see if you think it is suitable for adoption by > REGEXT, and comment to the list, clearly stating your view. > > Please also indicate if you are willing to contribute text, review text, or > be a document shepherd. > > This call for adoption ends Friday, 7 February 2020. > > If there are no objections, and we receive enough consensus for adoption, the > chairs will consider this document adopted. > > Thanks, > > Your REGEXT co-chairs Jim and Antoin > > > > > ___ > regext mailing list > regext@ietf.org <mailto:regext@ietf.org> > https://www.ietf.org/mailman/listinfo/regext > <https://www.ietf.org/mailman/listinfo/regext> > ___ > regext mailing list > regext@ietf.org > https://www.ietf.org/mailman/listinfo/regext ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] CALL FOR ADOPTION: draft-gould-regext-secure-authinfo-transfer
This call for adoption has ended with no objections. The chairs therefor accepted this document as a Working Group Document. For the WG: We still need a volunteer for this document to be the document shepherd. This is an excellent opportunity to get to know the IETF processes for new working group members, so please volunteer! No real technical insight about this draft is needed to volunteer, so don’t be shy. The only thing that you will need to do is to verify that all comments during WGLC and IESG review are attended to once the document reaches that state, and fill in a template about that process. This and all other things the chairs will help you with, but we need an independent document shepherd to state that the correct process was followed. For the authors: Please resubmit the latest version of your draft with the following name: draft-ietf-regext-secure-authinfo-transfer We have pre-approved the publication of this draft as a WG document. Regards, Jim and Antoin > Op 7 feb. 2020, om 15:42 heeft James Galvin het volgende > geschreven: > > Speaking with Chair hat on: > > Your message starts by suggesting that this work does not belong in this > working group but then moves towards discussing a solution for work that > belongs in this working group. > > As the CALL FOR ADOPTION comes to a close, the chairs are leaning towards > interpreting your message as agreement there is work that could be done. > Note that adopting the document does not guarantee that it will be published > by this working group; that will be decided as part of the discussion and > review. > > Is this okay with you? If not, please do take some time to clarify your > position. > > Thanks, > > Antoin and Jim > > > > > > On 28 Jan 2020, at 2:28, Patrick Mevzek wrote: > >> On Fri, Jan 24, 2020, at 09:51, Antoin Verschuren wrote: >>> This is a formal adoption request for Extensible Provisioning Protocol >>> (EPP) Secure Authorization Information for Transfer: >>> https://datatracker.ietf.org/doc/draft-gould-regext-secure-authinfo-transfer/ >>> >>> Please review this draft to see if you think it is suitable for >>> adoption by REGEXT, and comment to the list, clearly stating your view. >> >> While the subject of transfers between registrars might need work, >> I am not convinced this working group is the appropriate place for that, >> as in particular this document seems to mostly impose directives on >> registries >> and how they should handle and store domain passwords which is for me >> off topic for EPP as a protocol, and transfer issues cover points that are >> not completely technical but also business related, including the >> specific security model in which we want to work. >> (one might note that multiple procedure specify a transfer "undo" procedure, >> while this does not exist technically anywhere in EPP land...) >> >> As discussed in other threads, I am more leaning towards a ground up >> discussion >> on passwords attached to domains, and if other models can exist here. >> So I think work should instead go in that direction, which is then >> really completely EPP related, while discussions on passwords size, >> complexity, >> entropy, storage, TTLs, and so on as found in this draft are for me clearly >> out of scope of both the working group and EPP related specifications. >> >> The authInfo node was defined from the ground up to be extensible, >> and we should leverage that to put into place better mechanisms than >> current plain text passwords. >> >> I also fear discussions may forget there are already today other models than >> the "common" gTLD one that the draft tries to change, >> and I would like to make sure they are taken >> into account when drafting a solution. >> Among others, some registries use a "push" transfer model (so no >> passwords needed at all any more) and other registries basically do not >> let registrars set/handle passwords anymore, the first step of a transfer >> is the loosing registrar to ask the registry to generate a password that >> is in fact directly sent to the registrant, who in turn will input it >> at the gaining registrar (with some time window limits). >> >> Also while things should be left separate to be really able to produce >> new ideas, transfer issues can not be tackled without at least looking >> a little around RDDS and specifically RDAP, and around laws such >> as the GDPR from EU land, because this has the direct consequence >> for example that some registries do not continue to collect contacts, >
Re: [regext] CALL FOR ADOPTION: draft-gould-casanova-regext-unhandled-namespaces
This call for adoption has ended with no objections. The chairs therefor accepted this document as a Working Group Document. For the WG: We still need a volunteer for this document to be the document shepherd. This is an excellent opportunity to get to know the IETF processes for new working group members, so please volunteer! No real technical insight about this draft is needed to volunteer, so don’t be shy. The only thing that you will need to do is to verify that all comments during WGLC and IESG review are attended to once the document reaches that state, and fill in a template about that process. This and all other things the chairs will help you with, but we need an independent document shepherd to state that the correct process was followed. For the authors: Please resubmit the latest version of your draft with the following name: draft-ietf-regext-unhandled-namespaces We have pre-approved the publication of this draft as a WG document. Regards, Jim and Antoin > Op 7 feb. 2020, om 15:59 heeft James Galvin het volgende > geschreven: > > With chair hat on: > > As the CALL FOR ADOPTION comes to a close, the chairs want to thank you for > your comments and let you know we’re leaning towards interpreting your > message as a no objection. > > Would you like to clarify your position? > > Thanks, > > Antoin and Jim > > > > On 28 Jan 2020, at 2:10, Patrick Mevzek wrote: > >> On Fri, Jan 24, 2020, at 09:50, Antoin Verschuren wrote: >>> This is a formal adoption request for Extensible Provisioning Protocol >>> (EPP) Unhandled Namespaces: >>> https://datatracker.ietf.org/doc/draft-gould-casanova-regext-unhandled-namespaces/ >>> >>> Please review this draft to see if you think it is suitable for >>> adoption by REGEXT, and comment to the list, clearly stating your view. >> >> The subject can be interesting to the working group and might warrant an RFC >> (although registries and registrars worked for 20 years without trouble >> in handling this case, so one might imagine it is maybe too late or >> not a big enough problem). >> >> However, as discussed previously, in its current form this draft will >> introduce interoperability problems[1], so this just exchanges one problem >> with another. >> >> So I am mildly convinced work is required, and mildly unconvinced that >> the draft as it stands completely address the issue. >> >> [1] TL;DR: a registrar has no way to automatically discover >> a registry is using the mechanism outlined in this document, >> as not announced in the greeting part. >> >> -- >> Patrick Mevzek >> p...@dotandco.com >> >> ___ >> regext mailing list >> regext@ietf.org >> https://www.ietf.org/mailman/listinfo/regext > > ___ > regext mailing list > regext@ietf.org > https://www.ietf.org/mailman/listinfo/regext ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
[regext] WG LAST CALL: draft-ietf-regext-tmch-func-spec
The following working group document is believed to be ready for submission to the IESG for publication as an Informational document: https://datatracker.ietf.org/doc/draft-ietf-regext-tmch-func-spec/ This WG last call will end at close of business, Friday, 28 February 2020. Please review this document and indicate your support (a simple “+1” is sufficient) or concerns with the publication of this document by replying to this message on the list. The document shepherd for this document is Ulrich Wisser. Thanks! Jim and Antoin ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
[regext] Agenda items for IETF 107 Vancouver
Hello Working Group, It is time to start thinking of scheduling a WG meeting for IETF 107 in Vancouver. The deadline for requesting a meeting slot is due in 3 weeks. To get an impression on if and for how long a meeting slot we will need, this is a first call for agenda items. Does anybody have any topics to discuss? Regards, Jim and Antoin - -- Antoin Verschuren Tweevoren 6, 5672 SB Nuenen, NL M: +31 6 37682392 ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] [Ext] Magnus Westerlund's Discuss on draft-ietf-regext-data-escrow-06: (with DISCUSS)
Gustavo, I see that you have changed the Registrant contact in version 7 to "IETF ". It should however be: "IESG " - -- Antoin Verschuren Tweevoren 6, 5672 SB Nuenen, NL M: +31 6 37682392 > Op 7 apr. 2020, om 21:13 heeft Gustavo Lozano het > volgende geschreven: > > Thank you Magnus, > > I published version 07 to change the registrant in section 8: > https://tools.ietf.org/rfcdiff?url2=draft-ietf-regext-data-escrow-07.txt > > Regards, > Gustavo > > On 4/7/20, 05:39, "Magnus Westerlund via Datatracker" > wrote: > >Magnus Westerlund has entered the following ballot position for >draft-ietf-regext-data-escrow-06: 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://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_iesg_statement_discuss-2Dcriteria.html=DwICaQ=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM=VbweciUcwYQpIOZDSxl0ezGd1hGDtd-0BvgAgfmwfE0=H4H25qC-ozwnQrVC65Z1lf6p-zZuBuLJylW0eOXM2fQ=8nV-pq6KRFpWeSwexinVgILTShmLRTQjRv8A0VtHpxE= > >for more information about IESG DISCUSS and COMMENT positions. > > >The document, along with other ballot positions, can be found here: > > https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dregext-2Ddata-2Descrow_=DwICaQ=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM=VbweciUcwYQpIOZDSxl0ezGd1hGDtd-0BvgAgfmwfE0=H4H25qC-ozwnQrVC65Z1lf6p-zZuBuLJylW0eOXM2fQ=j2klZT-Dl_w-UWeqds8CleoflwjImgmPrBeQWGtfufQ= > > > > >-- >DISCUSS: >-- > >Section 8. > >As this document will be an IETF proposed standard I think the registrant > for >the RDE and XML schema shall follow the recommendation in RFC 3688: > > Registrant Contact > The individual/organization that is the registration contact for > the component being registered. Ideally, this will be the name > and pertinent physical and network contact information. In the > case of IETF developed standards, the Registrant will be the IESG. > >So please change that registrant to follow the above. The purpose of this > is to >prevent any issues over who has change control of the registered entries. > > > > > > > ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] WG LAST CALL: draft-ietf-regext-rdap-partial-response
Hi all, The chairs realised we did not formally close this Working Group Last Call yet, due to a discussion that was still going on on the mailing list. Even though there was not an enormous diverse amount of support stated on the mailing list for this document during WGLC, we have also not received any objections. The chairs would therefor like to formally close this WGLC now, and we will submit this document to the IESG for consideration. We will guide the document shepherds for this document to start their work on the writeup. Regards, Jim and Antoin > Op 28 feb. 2020, om 15:43 heeft Antoin Verschuren het > volgende geschreven: > > The following working group document is believed to be ready for submission > to the IESG for publication as a standards track document: > > https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-partial-response/ > > This WG last call will end at close of business, Friday, 13 March 2020. > > Please review this document and indicate your support (a simple “+1” is > sufficient) or concerns with the publication of this document by replying to > this message on the list. > > The authors are still looking for a document shepherd for this document. > Being a document shepherd is an awesome opportunity to get involved in the > IETF process. No deep inside technical review is needed, but it is a process > review that needs to be done by an individual not being one of the authors. > So please volunteer by replying to this message if you want this document to > move forward after WGLC. The author’s will thank you for it. > > Regards, > > Jim and Antoin > > > > > > > > ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] WG LAST CALL: draft-ietf-regext-rdap-sorting-and-paging
Hi all, The chairs realised we did not formally close this Working Group Last Call yet, due to a discussion that was still going on on the mailing list. Even though there was not an enormous diverse amount of support stated on the mailing list for this document during WGLC, we have also not received any objections. The chairs would therefor like to formally close this WGLC now, and we will submit this document to the IESG for consideration. We will guide the document shepherds for this document to start their work on the writeup. Regards, Jim and Antoin > Op 28 feb. 2020, om 15:43 heeft Antoin Verschuren het > volgende geschreven: > > The following working group document is believed to be ready for submission > to the IESG for publication as a standards track document: > > https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-sorting-and-paging/ > > This WG last call will end at close of business, Friday, 13 March 2020. > > Please review this document and indicate your support (a simple “+1” is > sufficient) or concerns with the publication of this document by replying to > this message on the list. > > The authors are still looking for a document shepherd for this document. > Being a document shepherd is an awesome opportunity to get involved in the > IETF process. No deep inside technical review is needed, but it is a process > review that needs to be done by an individual not being one of the authors. > So please volunteer by replying to this message if you want this document to > move forward after WGLC. The author’s will thank you for it. > > Regards, > > Jim and Antoin > > > ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] CALL FOR ADOPTION: draft-yee-regext-simple-registration-reporting
We will soon have 2 “RDAP” slots in our milestones available too. That’s where your 2 documents will fit in nicely Scott. I have recorded your request for adoption in the datatracker now too ;-). Regards, Antoin > Op 8 mei 2020, om 15:52 heeft Hollenbeck, Scott > het volgende geschreven: > >> -Original Message- >> From: regext On Behalf Of Antoin Verschuren >> Sent: Friday, May 8, 2020 9:37 AM >> To: regext >> Subject: [EXTERNAL] [regext] CALL FOR ADOPTION: draft-yee-regext-simple- >> registration-reporting >> >> Dear working group, >> >> We will soon have a slot available in our milestone list for a new >> EPP/Registry >> document. >> The chairs are not aware of any outstanding adoption requests other than >> this one. > > What about this one? > > https://mailarchive.ietf.org/arch/msg/regext/tcFV9CHPwxPEKwol4dNHgyAGHnU/ > > Sorry, maybe I shouldn't have embedded the request in what looks like an > innocuous message. 7483bis is also pretty much ready for consideration. > > Scott > > ___ > regext mailing list > regext@ietf.org > https://www.ietf.org/mailman/listinfo/regext ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
[regext] CALL FOR ADOPTION: draft-yee-regext-simple-registration-reporting
Dear working group, We will soon have a slot available in our milestone list for a new EPP/Registry document. The chairs are not aware of any outstanding adoption requests other than this one. This is a formal adoption request for Simple Registration Reporting: https://datatracker.ietf.org/doc/draft-yee-regext-simple-registration-reporting/ Please review this draft to see if you think it is suitable for adoption by REGEXT, and comment to the list, clearly stating your view. Please also indicate if you are willing to contribute text, review text, or be a document shepherd. This call for adoption ends Friday, 22 May 2020. If there are no objections, and we receive enough consensus for adoption, the chairs will consider this document adopted. Thanks, Your REGEXT co-chairs Jim and Antoin ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
[regext] CALL FOR ADOPTION: draft-hollenbeck-regext-rfc7482bis
Dear working group, Now that we have 2 more RDAP slots available on our milestones, we had new requests for adoption: This is a formal adoption request for Registration Data Access Protocol (RDAP) Query Format: https://datatracker.ietf.org/doc/draft-hollenbeck-regext-rfc7482bis/ Please review this draft to see if you think it is suitable for adoption by REGEXT, and comment to the list, clearly stating your view. Please also indicate if you are willing to contribute text, review text, or be a document shepherd. This call for adoption ends Friday, 29 May 2020. If there are no objections, and we receive enough consensus for adoption, the chairs will consider this document adopted. Thanks, Your REGEXT co-chairs Jim and Antoin ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
[regext] CALL FOR ADOPTION: draft-hollenbeck-regext-rfc7483bis
Dear working group, Now that we have 2 more RDAP slots available on our milestones, we had new requests for adoption: This is a formal adoption request for JSON Responses for the Registration Data Access Protocol (RDAP): https://datatracker.ietf.org/doc/draft-hollenbeck-regext-rfc7483bis/ Please review this draft to see if you think it is suitable for adoption by REGEXT, and comment to the list, clearly stating your view. Please also indicate if you are willing to contribute text, review text, or be a document shepherd. This call for adoption ends Friday, 29 May 2020. If there are no objections, and we receive enough consensus for adoption, the chairs will consider this document adopted. Thanks, Your REGEXT co-chairs Jim and Antoin ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
[regext] IETF 107 Virtual meeting timing
Hi all, In response to the discussion started by Jim on thoughts for a virtual meeting in the absence of the in person meeting in Vancouver, the chairs had responses that most people would like to have a virtual meeting to discuss the newly adopted documents and existing work. The IESG has produced a schedule for preferred dates for every working group that was supposed to meet in Vancouver to avoid conflicts with other working group's virtual meetings. The date dat was given to REGEXT is Monday April 27th. Before we officially request this virtual meeting slot, we would like to consult the group on the best times that are most convenient to most of the participants. Therefor we have set up a Doodle poll to indicate what time slot would fit you: https://doodle.com/poll/czir2xvs4snwfa35 Please fill in this Doodle poll and choose any start time of the meeting that could be working for you. We will be having a 2 hour meeting, so you should be available for 2 hours after the start time you select. As for the agenda, we will have an adjusted agenda out soon. We will not do our usual administrative check-up, but we will focus on the work that has been done. So far we have 4 presentations, and we will expect Authors of newly adopted documents to present an introduction of their document. Regards, Jim and Antoin ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] CALL FOR ADOPTION: draft-yee-regext-simple-registration-reporting
Dear WG, The call for adoption for draft-yee-regext-simple-registration-reporting ended 22 May 2020. The results were: Support: 4 valid Object: 0 The chairs considder this draft adopted by the REGEXT WG. Request to the authors: Now that the draft is adopted, you must look for a document shepherd for this document. If you have not yet found someone that has volunteered to be document shepherd for your document, please solicit for a volunteer in the working group. Working group members are encouraged to volunteer as document shepherd for this document. Being a shepherd is a great opportunity! Please submit a new version of the draft with the following name: draft-ietf-regext-simple-registration-reporting-00 The co-chair has already pre-approved this document so once submitted it will be automaticaly accepted as a WG document. Your co-chair Antoin > Op 8 mei 2020, om 19:40 heeft Owen Smigelski > het volgende geschreven: > > +1 > >> On May 8, 2020, at 8:44 AM, Joseph Yee > <mailto:j...@afilias.info>> wrote: >> >> +1 >> >> -Joseph >> >> On Fri, May 8, 2020 at 11:04 AM Mario Loffredo > <mailto:mario.loffr...@iit.cnr.it>> wrote: >> +1 >> >> Mario >> >> Il 08/05/2020 15:36, Antoin Verschuren ha scritto: >> > Dear working group, >> > >> > We will soon have a slot available in our milestone list for a new >> > EPP/Registry document. >> > The chairs are not aware of any outstanding adoption requests other than >> > this one. >> > >> > This is a formal adoption request for Simple Registration Reporting: >> > https://datatracker.ietf.org/doc/draft-yee-regext-simple-registration-reporting/ >> > >> > <https://datatracker.ietf.org/doc/draft-yee-regext-simple-registration-reporting/> >> > >> > Please review this draft to see if you think it is suitable for adoption >> > by REGEXT, and comment to the list, clearly stating your view. >> > >> > Please also indicate if you are willing to contribute text, review text, >> > or be a document shepherd. >> > >> > This call for adoption ends Friday, 22 May 2020. >> > >> > If there are no objections, and we receive enough consensus for adoption, >> > the chairs will consider this document adopted. >> > >> > Thanks, >> > >> > Your REGEXT co-chairs Jim and Antoin >> > >> > >> > >> > >> > >> > >> > ___ >> > regext mailing list >> > regext@ietf.org <mailto:regext@ietf.org> >> > https://www.ietf.org/mailman/listinfo/regext >> > <https://www.ietf.org/mailman/listinfo/regext> >> >> -- >> Dr. Mario Loffredo >> Systems and Technological Development Unit >> Institute of Informatics and Telematics (IIT) >> National Research Council (CNR) >> via G. Moruzzi 1, I-56124 PISA, Italy >> Phone: +39.0503153497 >> Mobile: +39.3462122240 >> Web: http://www.iit.cnr.it/mario.loffredo >> <http://www.iit.cnr.it/mario.loffredo> >> #pleasestayathome >> >> ___ >> regext mailing list >> regext@ietf.org <mailto:regext@ietf.org> >> https://www.ietf.org/mailman/listinfo/regext >> <https://www.ietf.org/mailman/listinfo/regext> >> ___ >> regext mailing list >> regext@ietf.org <mailto:regext@ietf.org> >> https://www.ietf.org/mailman/listinfo/regext > ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
[regext] WG LAST CALL: draft-ietf-regext-rfc7483bis
The following working group document is believed to be ready for submission to the IESG for publication as a standards track document: https://datatracker.ietf.org/doc/draft-ietf-regext-rfc7483bis/ This WG last call will end at close of business, Friday, 2 October 2020. Please review this document and indicate your support (a simple “+1” is sufficient) or concerns with the publication of this document by replying to this message on the list. The document shepherd for this document is Jasdip Singh. Regards, Jim and Antoin ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
[regext] WG LAST CALL: draft-ietf-regext-rfc7482bis
The following working group document is believed to be ready for submission to the IESG for publication as a standards track document: https://datatracker.ietf.org/doc/draft-ietf-regext-rfc7482bis/ This WG last call will end at close of business, Friday, 2 October 2020. Please review this document and indicate your support (a simple “+1” is sufficient) or concerns with the publication of this document by replying to this message on the list. The document shepherd for this document is Mario Loffredo. Regards, Jim and Antoin ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
[regext] Call for agenda items for IETF 109
Hi all, This is a call for agenda items for the IETF 109 virtual meeting. The chairs plan to request a meeting slot, but we would like to know how long a session is needed.. A special note to authors of newly adopted or an active draft on our milestones list: If you want your document to proceed, it would be wise to ask some time on the agenda to discuss your document. Regards, Jim and Antoin ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
