IETF
regent
regext@jabber.ietf.org
Monday, July 16, 2018< ^ >
SHollenbeck has set the subject to: REGEXT WG at IETF-100
Room Configuration
Room Occupants

GMT+0
[15:25:06] Yoshiro Yoneya joins the room
[16:12:24] Yoshiro Yoneya leaves the room
[17:43:20] Yoshiro Yoneya joins the room
[18:28:24] Yoshiro Yoneya leaves the room
[18:28:29] Yoshiro Yoneya joins the room
[18:43:29] pmevzek@xmpp.dk joins the room
[18:56:43] pmevzek@xmpp.dk leaves the room
[18:57:11] Patrick Mevzek joins the room
[18:58:51] Patrick Mevzek has set the subject to: REGEXT WG at IETF-102
[19:34:32] meetecho joins the room
[19:41:54] cmXTdgmA joins the room
[19:45:04] Martin Casanova joins the room
[19:46:23] Antoin Verschuren joins the room
[19:46:49] Patrick Mevzek_7142 joins the room
[19:47:06] Yoshiro Yoneya joins the room
[19:47:24] Yoshiro Yoneya leaves the room
[19:48:19] Lorenzo Miniero joins the room
[19:48:38] <Martin Casanova> hi all !
[19:49:20] Jaromir Talir joins the room
[19:50:29] <Patrick Mevzek> hi Martin, and all!
[19:51:36] Jody Kolker joins the room
[19:52:17] <Jody Kolker> Hi Martin/Patrick and everyone!
[19:55:55] <Antoin Verschuren> Hi All. The volume is a bit low, or is that just me?
[19:56:05] <Patrick Mevzek_7142> Mine is ok.
[19:56:14] <Martin Casanova> mine too
[19:56:26] <Jody Kolker> I'm hearing it well.
[19:56:33] James Galvin joins the room
[19:56:43] <Antoin Verschuren> OK, then I'll go looking for hidden slides :-)
[19:57:04] <James Galvin> There are no slides for this discussion.
[19:57:26] <James Galvin> The slides for James Gould's discussion were uploaded to materials this morning.
[19:58:15] James Galvin joins the room
[19:58:24] James Galvin leaves the room
[20:00:28] <Patrick Mevzek> @Scoot exactly about the IPR: any more information so that no to be again in same case than keyRelay ?
[20:00:33] <Patrick Mevzek> @Scott sorry
[20:01:23] <Patrick Mevzek> "so that not to be again"
[20:03:19] <Patrick Mevzek> about separation: there is no tie if you structure top elements to be RFC numbers or ID or XML namespaces…
[20:05:39] shinta joins the room
[20:11:28] Jody Kolker leaves the room
[20:14:04] Jody Kolker joins the room
[20:15:14] <Patrick Mevzek> third one: ISO8601
[20:15:29] Jody Kolker leaves the room
[20:15:30] Jody Kolker joins the room
[20:15:52] Jody Kolker leaves the room
[20:15:53] Jody Kolker joins the room
[20:16:02] <Patrick Mevzek_7142> I can not request the mic for audio, so if someone could take into account the above text for discussions...
[20:16:15] Jody Kolker leaves the room
[20:16:16] Jody Kolker joins the room
[20:16:34] Jody Kolker leaves the room
[20:16:35] Jody Kolker joins the room
[20:18:25] <Patrick Mevzek> Will try to post example later on mailing-list. But basically something like <registry:object type="rfc5731">… all domain policy items</registry:object>
[20:18:51] <Patrick Mevzek> <registry:object type="draft-whatever-extension">… policies param for those</registry:object>
[20:18:55] <Patrick Mevzek> etc...
[20:18:57] vlevigneron joins the room
[20:19:11] <Patrick Mevzek> I am here and I hear but I can not talk :-)
[20:19:47] <Patrick Mevzek> (sorry about that)
[20:20:37] Francisco Arias joins the room
[20:21:17] <Patrick Mevzek> v4/v6: i think there are such registries, from memory… will try to find them.
[20:21:46] <Patrick Mevzek> work comment however: you can not expect all registries to be there or hear about this workgroup, we *will* miss cases...
[20:22:57] <Patrick Mevzek> LGR: if they are not used, why was a standard build for them? The idea was for them to replace IANA tables at some point, right?
[20:24:11] <Patrick Mevzek> No, you can not have 2 ints or 2 locs. But see my example on TRAVEL in the mailing-list
[20:26:20] <Patrick Mevzek> TRAVEL: int only or int+loc together, not loc alone (that was my example)
[20:26:46] <Patrick Mevzek> other rules like: which characters can be used at same type (multiple scripts or not at the same time, etc.)
[20:28:00] <Patrick Mevzek> LGR => iana tables: yes but not completely there are things that you can not encode in current IANA tables
[20:29:41] <Francisco Arias> @Patrick: could you elaborate on the things that cannot be encoded in the current IANA tables?
[20:30:23] <Patrick Mevzek> I believe things like: this character can only appear after this character, not everywhere in the string.
[20:30:44] <Patrick Mevzek> (I may be wrong, I do not have the full tables spec in mind right now, but there is a lot of things in LGRs...)
[20:30:49] <Francisco Arias> I thought that is supported in the LGR format, no?
[20:30:58] <Patrick Mevzek> Yes it is possible in LGR !
[20:32:24] <Patrick Mevzek> About contact IDs: I agree on the technical aspect (not grandfathering deviations) but on the other side if any small think is not possible to encode in this new extension, registries WILL NOT use it, and you are back to the 40 pages Excel spreadsheet
[20:33:01] <Patrick Mevzek> The question is really: which registries want to deploy this extension? It would be happy to see a lot/many of them do it, but if the barrier is too high noone will…
[20:34:13] <Patrick Mevzek> if any small thing can not be encoded...
[20:35:23] <Patrick Mevzek> yes, I agree with James, leave it out to base, just make sure it is possible to easily extend it for local deviations
[20:36:30] <Patrick Mevzek> "leave it out of base"
[20:38:22] gustavo.lozano joins the room
[20:38:30] koji joins the room
[20:44:42] Lorenzo Miniero leaves the room
[20:45:16] Sean Baseri joins the room
[20:49:52] swapneel sheth joins the room
[20:51:58] <Patrick Mevzek> real life experience: registries happen to send messages not conforming to their own (extension) XML schema. Sad, but exists.
[20:56:07] <Martin Casanova> I dont think creating a poisoned message is a good option, only alternative I see is to not send any extension in the poll msg that was not not specified...
[20:56:20] <Martin Casanova> at all
[20:56:38] <Patrick Mevzek> Martin: Both cases are bad for registrars…
[21:00:33] Sean Baseri leaves the room
[21:00:59] <Patrick Mevzek> re reading rfc5730, msgq (with underlying message Id) can indeed by in any reply….
[21:01:08] <Patrick Mevzek> I am not sure it is good to send it in case of errors
[21:01:21] <Patrick Mevzek> "can indeed be"
[21:03:48] <Patrick Mevzek> Scott: not agree completely. If on day X a registry starts to add a new URI to greeting, and the client does not use it and the login is authorized (hence this extension is not mandatory) then the client IS CONFORMING. But there could still be the problem of the server having a message with a namespace not understood by client
[21:05:28] gustavo.lozano joins the room
[21:06:39] <Patrick Mevzek> Scott: how does the registrar knows it is missing on messages? no info for it about that!
[21:06:52] <Martin Casanova> poll messages can not be skipped.
[21:06:53] <Patrick Mevzek> (if server skips messages in the queue)
[21:07:20] shinta leaves the room
[21:08:29] <Patrick Mevzek> agree with james, this is not transparent. the registry can start enqueing new messages with new URI and the registrar is already in an EPP session...
[21:10:07] <Martin Casanova> Since we have already a solution approach with no major downside why not vote for option 3?
[21:12:59] <Patrick Mevzek> @Martin kind of agree in the sense that latest option with extValue is the less worse of all of them but personally I am still not sure it is a problem to solve, I am very suspicious how many registries will implement it (in which case a RFC is not mandated) and while not written in stone extValue seems to me more related to errors
[21:13:29] <Patrick Mevzek> @Scott: as father of RFC5730 can you give us more insights about the intent you had behind extValue… only for errors or in general?
[21:14:43] <meetecho> Working on the missing slides for remotees...
[21:16:17] <Patrick Mevzek> No it is not the end of it: again the case of DNSSEC in domain:info where it needs specifc accreditation so clients may not use it in all cases…
[21:20:07] gustavo.lozano leaves the room: Connection failed: connection closed
[21:33:40] <Jody Kolker> Where is it stated in the Temp Spec that these are required?
[21:35:03] <Jody Kolker> Agree with RIck.
[21:37:37] <James Galvin> @jody - not that searching is required but if you are doing it in WHOIS you need to carry it forward.  As rick said, even this is subject to interpretation.
[21:38:30] <Jody Kolker> @James - Agreed - is any registry or registrar now allowing wildcard searches?
[21:38:47] <James Galvin> we offer some limited options
[21:43:18] <Jody Kolker> I have concerns with how many domains will be returned?  If a search if for the street address that is used for privacy, millions of domains would be returned.  That will be add to the compication of this implementation.
[21:44:21] <Jody Kolker> Same issue would be for a domain wildcard search of domains that start with "s*".
[21:48:36] Francisco Arias leaves the room: Stream reset by peer
[21:49:03] gustavo.lozano leaves the room: Connection failed: connection closed
[21:49:05] <Patrick Mevzek> Thanks, see you
[21:49:11] <Martin Casanova> Bye bye
[21:49:25] <Jody Kolker> Thanks Everyone!
[21:49:38] Jaromir Talir leaves the room
[21:49:58] Antoin Verschuren leaves the room
[21:49:58] Jody Kolker leaves the room
[21:49:58] Patrick Mevzek_7142 leaves the room
[21:49:58] swapneel sheth leaves the room
[21:49:59] Martin Casanova leaves the room
[21:50:06] meetecho leaves the room
[21:53:32] Yoshiro Yoneya joins the room
[21:56:25] James Galvin leaves the room
[21:57:40] Yoshiro Yoneya leaves the room
[22:04:55] Yoshiro Yoneya leaves the room
[22:06:26] koji leaves the room
[22:09:02] vlevigneron leaves the room: Disconnected: closed
[22:53:11] Francisco Arias joins the room
[23:22:42] Francisco Arias leaves the room
[23:37:49] Patrick Mevzek leaves the room
Powered by ejabberd - robust, scalable and extensible XMPP server Powered by Erlang Valid XHTML 1.0 Transitional Valid CSS!