CoRE WG - Summary IETF97
Raw Minutes: http://etherpad.tools.ietf.org:9000/p/notes-ietf–97-core
Summary below, followed by detailed minutes.
draft-ietf-core-block ➔ RFC 7959 [✔]
draft-ietf-core-http-mapping still processing some DISCUSSes; will move to Proposed Standard status to clear one of them.
draft-ietf-core-etch submitted to IESG. Waiting for Alissa’s DISCUSS [now cleared]. Next is to get it to implementors.
draft-ietf-core-object-security current draft stable; reviews, 2 implementations available. 15 people read some version, 5 have read latest. Need more feedback from implementors before WGLC. Target is to have an interop mid-January 2017; we’ll label one of the net drafts as “implementation draft”.
draft-ietf-core-coap-tcp-tls addresses issues since IETF 96, currently on WGLC. Discussion on whether to make TLS a must or to open option for alternative security mechanisms (e.g. OSCoAP). Interesting insights on vendors’ usage of certificates. Authors to set up a call addressing Security and remaining issues about 2 weeks after IETF. Target is WGLC about 4 weeks after IETF.
draft-silverajan-core-coap-protocol-negotiation now using RD instead of .well-known/core. 3 people read the document and 7 will read it.
draft-ietf-core-resource-directory moving forward. Authors to address remaining issues. OCF to organize a call. Text on DNS-SD requires feedback, might be published as a different draft.
draft-ietf-core-dynlink no time ➔ Friday
draft-ietf-core-interfaces no time ➔ Friday
We used an informal “hallway” meeting to have time for some informal discussions about upcoming work and/or potential revisiting of old work.
draft-ietf-core-links-json Presentation about status and updates. Proceeding further as planned.
draft-vanderstok-core-coap-est and draft-pritikin-coap-bootstrap: how to use EST over CoAP. To be done in ACE WG. Issue for CoRE: Do we need a new 2.06?
draft-tiloca-core-multicast-oscoap Solves RFC7390 issue with securing multicast but independent of use case.
draft-cao-core-delegated-observe enables delivery of observe responses to different addresses than where the request came from. Feedback: of interest to others. Security (spoofing) is an issue. Documentation of the problem can be done as draft-ietf-lwig-coap addition or T2TRG topic.
draft-groves-coap-webrtcdc: like CoAP-TCP/Websockets, but over WebRTC data channel. Should go ahead after CoAP-TCP is completed.
draft-nottingham-rfc5988bis–01 revision is coming. CoRE should be aware of new changes, now is the chance to affect them.
draft-groves-core-dynlink about 3 people have read the draft, the group should read it and provide feedback.
draft‐ietf‐core‐interfaces it’s decided to remove the “function set” concept since people do not consistently use it. There should be allignment with SDOs in the space, like OCF.
draft‐groves‐core‐senml‐bto about 3 people have read the draft. One problem is that there are only few people who know how EXI works, in W3C. Discussion on BTO support and how to announce it to clients. Extensions to be left out of the main SenML draft.
draft-ietf-core-senml new discussion on fragmenting, registrations for copy-pasting SenML (easy to do, so probably should) and metadata labelling (strong support).
draft-ietf-core-yang-cbor to be tagged as an implementation draft, next steps are to submit final version by January, interop in February and in IETF98.
draft-ietf-core-sid the point of the draft is to use global identifiers assigned to YANG items for different functionalities. There was interest by DTN folks to use this work too. There was discussion on flat vs hierarchical namespaces. Open issues are the reservation of SIDs in the namespace. Target is IETF99. WGLC March 2017.
draft-vanderstok-core-comi from v09, adds usage of SID, iPATCH/FETCH support, YANG to CBOR, Content format (WIP) and new query parameters. About 10 people have read and wanted to adopt this document. To be taken to the mailing list for discussion.
draft-thaler-core-redirect intention is to redirect from non-secure server to secure one. Main problem is that it misleads the client. Better way would be to spend more time on hypermedia formats to get this right. Problem is general, several contributors volunteered to work on this.
draft-groves-core-rfc6690up-latest issues with RFC6690 IANA registration procedures for (rt) and (if). On the one hand it is a bad idea create different namespaces as it does not help interoperability. On the other you don’t want to squash innovation, SDOs like OCF need to register their resource types. For now a good way forward is to help with more expert review recommendations and with a high threshold prefix registration.
[13.32] meeting starts
13:30–13:40 Links-JSON (CB)
13:40–14:00 CoAP in ANIMA (BRSKI, EST-coap) (PV)
[Jim]: I am familiar with EST. What is BRSKI on top of EST. [PV]: BRSKI uses EST to transport all the key information. [Carsten]: We could discuss here the overall approach. [PV]: BRSKI approach is quite heavy. Still ongoing discussion how to do this. [Carsten]: We could also discuss Media Type in EST and type response over EST that is not there yet. [PV]: human looking at the security is optional. [Carsten]: why need 2.06? [Jim]: it may take time to produce the answer. [PV]: may go back to manufacturer or something more complex where the reply comes from [Carsten]: What timespan are we talking about? [PV]: not absolutely sure; from half a second to some minutes [Carsten]: wonder if something for CoAP needed for slow answers [PV]: draft suggests way to handle this, from Klaus Hartke. Not sure where to do this work. CoRE has already many items [Carsten]: Maybe the right working group would be Ace [Jim]: much more ACE kind of thing [Carsten]: except for 2.06. Rest look like ACE issues. ACE meeting right after this. Who in room familiar with EST? >3 people [Ari]: I am not familiar with EST, so I don't have a feeling if this is good or bad [Jim]: EST is basically a HTTP based protocol that uses well-known endpoints for posting PKCS#10 certificate requests to. It has some additional end-points that can be used to get CRLs and do revocation. [Ari]: How does this compare to LWM2M? [Jaime]: LWm2M has bootstrapping and after the DTLS or TLS session is placed the manager can update security credentials on the devices. [PV]: Not seen any immediate attachment, but in OMA you also have the problem on how to secure a new device. [Jim]: Has Anima group looked at MUD? [PV]: Good question. [Brian ???]: MUD URI can go into the manufacturers certificate, it works very well with the BRSKI bootstrapping. [PV]: lots of discussion of using MUD in ANIMA [Brian]: Don't know.
14:00–14:10 Object Security for multicast (FP)
Carsten: (on slide 83) what is in the message? FP: same as OSCOAP. Carsten: how context becomes a context? Jim: multicast enrollment protocol Carsten: how parties learn context? Francesca: context must be pre-established before communication. Foo-context is established based on input parameters (see OSCOAP preso). Would include base key and context ID and algorithm. Now also pub/priv key pair. Everything else derived from there. Carsten: Does receiver 2 have to know that receiver 3 is there as well? (slide 83) Francesca: no. Each listener is only aware of itself and broadcaster. Broadcaster need to now listeners to verify responses. Carsten: if you have pairwise symmetric keys btw broadcaster and listener can those be used to send the response? F: Yes. Carsten: can do PSK in one direction and RPK other? Francesca: Yes. PSK is used all the time and counter-signature too for source verification. It is easy to do source verification but don't need to (following wg decisions).
14:10–14:20 Delegated Observe (ZC)
Matthias: hinted that 2–3 years ago with Klaus talked about multicast notifications. Sending serial unicasts to large number of of observers costly. Multicast tricky so no real work so far. For original Observe wanted to avoid delegation to avoid bombarding with messages random nodes; didn't feel good design. Carsten: if you look at this example (Delegate Cloud): don't see why an end device cannot tell the cloud to do the Observe Dave Robin: The cloud server cannot go through the firewall, but a device in the same network can go out. Classic BACNET problem. New version(RESTful): add a message "it wasn't me" Michael: working on similar thing on CoRE interfaces; binding. Working on generalizing with "monitor". Dave: the one doing the binding is not necessarily one of the parties in communication. Three party thing. The one doing the binding is not necessarily interested in the data. Michael: Could be a configuration tool. We should come up with a single approach to solve this problem. Will review this draft.Will need to review what's in CoRE interfaces and binding. Carsten: one of the problems apart from the authentication is that this figure (Recap: direct Observe slide) is incomplete because the token is missing. The notification has to carry a token that the original sender of the request has allocated. Device may allocate a token for reply but the receiver don't understand what's the token about. Zhen: But token is optional? Carsten: No. There is always a token. There is nothing in the response message that tells you what the request was about except for the token. This needs to be solved for the delegate observe case. Who manages the token space. [Explaining how HTTP2-push solves the problem of one way communication without solicitation safely] … Michael: HTTP2 solves that with the push promise. Dave: My answer is that the URI is actually very long token that includes a lot of data. Carsten: Originally we didn't do this cause it makes it bigger and its easy to spoof. If you have some security it's harder. In NoSec mode it'd be a problem. The 32bit token gives some security against off-path attackers. Token in Security Consideration of RFC7252. This is not in CoAP today because (this has been discussed and) .. Which parts do we want to add to make these scenarios work? Zhen: In normal home network case it's solved by having sensors sending directly to cloud. To send data to anothe cloud service, this could be a good fit. Benefit of this can have some node in the home network to tell to different destination. Can take discussion to the list. Carsten: Who in this room thinks that there is a problem that we should solve at some point? ~10 Carsten: So the rest doesn't care? Anna: we're not using multicast David Robin: Separate use case: I may not need the multicast scenario but I may need the other. Laurent: Concern on security this enables DDOS. Carsten: Important to analyze security and how to keep same level of sec by the token. Matthias: It is quite open to say: yes we want to solve it but most may not understand exactly what is the problem, can we define this? How does this work with intermediaries? This document is more of a specific architecture solution. Ari: this is only one case of the general pattern. Matthias: Is this the small thing we solve or would it be better to have a discussion on the big picture? Architectures with intermediaries or more than one client have gotten very little attention so far. Jaime: In OMA similar issues arised, and they have solved them within the SDO for their use cases. IETF CoRE is seen as a tech component maker. Michael: (to Matthias) There is a number of problems that arise with Observe, like conditional observations, and need to be looked at. Many are very related to what you say. All of these things (limitation to observe pattern) need to be looked at in the context of the overall system. Alex: Agree with Ari, solve this problem of 3 nodes, one telling second to talk to third; this is already difficult. Dave R: About complexity: this simple case is the piece we need to solve. We should start with this and solve it. Need solutions for the attacks; many ways to do that. Simple 3-party thing has plenty to work on. Carsten: What you could do (Zhen) is to tell the local device to open a DTLS connection to IoT Cloud server and the server then sends the request to receive notifications (i.e., CoAP server is DTLS client). We agree there are problems but several ways to address them. Good to document the solutions that come in mind and see what can be solved with today's tools and what needs new tools. PV: All the solution depend on the tools you use Christian A: As far as I understand, everything now being talked about is rather about the multicast use case than for the cloud server firewall-piercing use case. Do you see the need for the latter? IMO, this should rather be solved via some kind of RD or TCP. Carsten: Valid opinion, we need more documentation on the solutions. Document that describes these would be useful. Matthias do you want to add this to the draft-ietf-lwig-coap? Michael: Could this also be a T2TRG research topic? Carsten: Yes. Very valid topic.
14:20–14:30 CoAP over WebRTC DC (CG)
Carsten: Can I implement that or do I have to wait for the browser vendor to implement that? Christian: can implement, just indicate with sub protocol. There is already one implemented for CoAP. Carsten: What WebRTC implementations using today over DC? Christian: MSRP, BFCP, and one more Michael: would be appropriate for transport control? stop, pause, back, etc. Can use those with CoAP? At OCF transport control device mapped to CoAP. Would make sense to use this? Christian: Yes potentially, you could use these. Wouldn't solve the channel problem. Original idea for gaming etc. Michael: it would be a sub-channel that would take care of (…missed it) Matthias: why included new features with stream based CoAP? Is WebRTC stream based? Carsten: there's SCTP Christian A: Camera control could be an application too – think of what we're doing with the meetecho cameras Christian: true, already controls for that, but this can be used too Carsten: W3C is also working on browser API for sensors. CoAP could be intersting in that context.
14:30 - on Flextime
CoAP over TCP: mostly editorial issues
Issue #69 at the Github tracker:What exactly is the mandate on ping pong messages. Right now is: “there is a ping, and pong is the answer” doesn’t tell you MUST answer pong. What are people expecting ping pong messages to do? Other uses? One use may be RTP messages (only works if the other side reply quickly).
Ari: Is there a use to delay the pong? Carsten: If there is things in the queue to do before. Right now it does not say anything. Should we say more? Makes sure we define it in a useful way. Christian: It depends on what the sender wants to do. Carsten: interesting phrase: "without undue delay" used in RFC7252. Brian: Common pattern used in websockets and HTTP2. There is a bit too much "CAN language" in my opinion. Different uses; for RTT or if messages have been processed. Overloading this here. Carsten: keep thinking about how to use ping and pong and bring this discussion to the mailing list.
Dave Thaler: OCF has a reference but this functionality not in certified 1.0. So it's OK to change this. But if this becomes way to do versioning, maybe this should become the way to do versioning with OCF. OCF clear that RD and TCP are not certified but are experimental. Michael: agree
Brian: Bikeshed from IETF96. Either Priviledging CoAP or WS. Carsten: It is going to confuse implementers for years ahead. Brian: could solve with coin toss
Carsten: will prepare some slides summarizing what was said today and present on Friday.
Latest slides at https://www.ietf.org/proceedings/97/slides/slides–97-core-consolidated-slides–06.pdf
Akbar: will this be pointed out in the WG and coap.technology pages? Carsten: those running sites about CoAP should make sure that happens. It’s in options registry, but otherwise a bit hidden perhaps
Mark N: have been working on weblink bis for a while. RFC5988bis Ready to become more formal. If you have needs for something in this doc, get in contact. But bis doc so only limited changes planned. Carsten: one issue; too few registries in the weblinking.
Carsten: Leftovers from Wednesday will consume “flextime”. CoAP over reliable transports will be discussed at the mailing list.
Christian G presented updates.
presentation of issues left:
Function sets not easy to understand. Could remove function sets concept.
RFC6690 introduces “if” attribute, but does not say what should be on a description model, question on whether it should be elaborated.
RD and OCF terminology alignment also needed
Should remove function sets? Separate doc?
Michael K: hallways discussion consensus: remove function set. People not using consistently. Rather use few words to describe in place what is actually meant. Either update everywhere or remove and replace with description language. Interface description: we might want to focus on whant an interface does, and then give an OCF as example. Already OCF registrations. We should not register new ones that do what OCF ones do. Example ocf.ll already registered, should not register core.ll? Christian G: need to consider in naming the registered prefixes and suffixes Carsten: good way forward. Update the draft
Carsten: who has read a version of this draft? ~3 Ari: thanking for work. CBOR and EXI analysis correct. CBOR can parse a document even when there is extension not present before. Any EXI experts? Carsten: General problem is that there are only few people who know how EXI works in W3C. We should try to find experts. Cristian G: BTO support Ari: If you support video and .. you also support BTO. There is a difference between understanding parsing and handling. Cristian G: Problem with CBOR Ari: Schema vs BTO CarsteN: The schema should imply "i can decode this" not "i implement all options" Ari: new issue: Do we need an option for "I saw something (could parse) but I didn't understand it (don't know how to handle it)." Dave Robin: If I see BTO but don't support BTO I have to reject the message somehow. On BACNET optional functionality not supported message. The client can then fallback to prev version. When you extend and there is a fallback is good to be more explicit on the response. Carsten: Is BTO a useful extension? Ari: Yes. how do we indicate it? Dave: "MUST understand" from SOAP signifies that the request needs to be rejected if not supported. Ari: adds complexity. Carsten: No need to solve this here. For the authors to solve. Michael K: Is it there a notion of SenML validation? We should find a better solution than the one in the text. We talked about other things like extending for URLs. TBD. Ari: Other option we don't do it at all. Keep it very simple. But it's a tradeoff, because this would make this kind of extension impossible. We want SenML out, it's been out too long, I propose we keep it single.
Carsten: This is a feature that a CBOR to JSON can have but not vice-versa.
Michael Koster: Does this impact the statement in RFC6690 about not supporting fragments? Ari: Don't remember what 6690 says about fragment IDs. Will look into that. Michael: RFC5988 has guidelines about that. Carsten: RFC2616 had a bug on text on fragments and that bug was copied in RFC7252. Fixed in RFC7230 (more recent). NOTE: RFC7252 section 4.6 talks about fragmentation. Christian G: ? Ari: This idea came up a few ideas ago Henk: People might use batch mechanism to transport something else than readings. Might be used on the pubsub draft. Ari: does not apply. this requires something else on server. Michael Koster: It would be useful feature (fragment). Ari: Some value on it, but maybe needs a real use case. Lets take it to the mailing list.
Copy-pasting Senml. (Audience: shrugging and nodding) – won’t do harm, let’s register identifiers
Metadata “m” label
Christian G: Are there existing attributes that you'd need to update the character set. Ari: No, this would be the only one. Christian G: concerned about updating an existing attribute. Jari: Support the idea, we can extend it later. Ari: Seems to be support from people to do this as extension.
Presentation by Alexander Pelov. Introduction: CoMI the main draft. CooL for more advanced features and future work.
Carsten: Do we want to tag next version as an implementation draft? Trigger to hand over to NETMOD. Alexander: Yes, in January. Now the right time to have a look at the draft.
Rick Taylor: I like it, looking from DTN side. Liked to use YANG but can't handle massive IDs. What I didn't realize from the you have a flat ID space, everything is uniquely named. Might generate so many SIDs. Alex: discussed this topic lot, want to have complexity at compile time. Registry system where register all these things in efficient way. It's 32 bits, so pretty large. Rick: with dotted notation can refer to part of the directory. Can talk of just little sub tree. Especially good for constrained environment. We do this with delta encoding. Everything is 1–2 bytes on wire. Alex/Carsten: we do this with delta encodings. Rick: Does it work if I extend the model and I have lots of SIDs, my delta would be just as big as the original value. Alex: in this case delta could be quite big (not more than the bytes for the sid itself). When you have a list of operations, your delta will be really small. Edward Birrane: EPL another question is: Is there a reserve name spaces? What if some identifiers needed to be added in later on? Will they get a further position in the registry. Alex: excellent question. What we want is a very lean draft. You will be able to reserve for (future) consecutive IDs. Wouldn't want to overspecify, would like to finalize this draft without wasting months to think about the algorithms. Edward: The comment is that identifying groups is something useful. Large text names have grouping mechanism. Peter VDS: I sympathize with the hierarchy argument but it is too complex. SDOs can prepare their own modules and reserve the space for them Carsten: If you really want a hierarchy you can use ASN1 object IDs. With SID we try to make flat spaces work. You can also save few bits for expansion. For toaster example, even if we have only few types of bread today, we can reserve for future types. Rick Taylor: To finish here. Although we have similar use cases they are certainly different, in DTN the payload is much larger. We do not have the same compression limitations. Thanks for the explanation. Alex: Happy if you can reuse. Rick: I think MAYBE.
Carsten: if skeptical of approach, we have running code Rick T: Is YID being discarded instead of SID? Carsten I just found your YID draft, is this discarded in favor of SID? Carsten: This is what we are discussing here. Rick Taylor: YID draft can be used on the DTN domain. Alex: explaining how to do YID with SID. Rick: I see the advantage of SID. But depends on how you do the CoAP management protocol. If you want to do e.g., "give me everything under this" or xpath selecting, with sid it will be very difficult. Alex: YID has constraint that range is size power of 2 (last bits). Rick: I think you are losing the structure. Carsten: Rice-Golomb encoding can be used if you need more structure, but that uses more bits too Rick: On DTN use cases we are happy to leave the compression in exchange for more power.
Peter Van Der Stok
Updates from v09. Usage of SID, iPATCH/FETCH support, YANG to CBOR, Content format WIP, new query params…
Differences with RESTCONF
Carsten: who has read a recent version? ~10 Who wants to adopt this document? ~10 Who doesnt? 0 hands. So positive outcome, we will confirm this on mailing list. Rick Taylor: YANG push for disconnected verifications? Peter VDS: No opinion.
Carsten: two reasons for not redirect. 1) don't want the state machine 2) re-direct is circumventing state machine. Server leads the client. In HTTP most implementations do this automatically; client does not think about this. Violation of REST. Application should decide whether to follow lead. Will run into all problems or redirect in HTTP world. Stack redirected to do something can be exploited in wonderful ways. Adding state machine now seems wrong. The two figures are equivalent. How do we expect developers to implement this? Big danger around re-direct. How to do non-redirect solution? You could do this link format to any type of discover request. Not revealing OCF specifics. Link format one interesting additional point: it can add attributes on how this thing can be executed. Link format sounds like a good way to handle this. The disadvantage: address and path need to be repeated. Dave T: Agreed. Matthias Kovatsch: Not sure redirect is the right solution, a lot of changes that should be applied. Can imagine similar problems in other applications dealing with OCF. Would prefer having the information on the payload itself . At T2TRG working on this. Content format suitable for linking (e.g., CoRAL). About other issue: maybe 4.00 what you want to return. Leave the control & decision to client. Carsten: You don't respond with 4.00 to a multicast. Matthias: OK, more details to multicast, may want to apply something similar though. More flexible solution would be better (link format or new approach). Would recommend on investing time on exploring solutions. Dave T: You are arguing for link format due to existing extensions, right? Matthias: better to invest more time on hypermedia formats to get this right. Michael Koster: link relation can be used to solve ambiguity. Can make explicit informing client what to do. Dave Robin: Point to Auth Server is helpful but is also a Privacy problem. Can point to authentication server to do stuff. Dangerous to add such a feature. Dave T: Good point. Furthermore, what happens in the DTLS exchange is a job for the CFRG. Dave T: What I'm hearing is general feedback to use 3.00 and link format. Is there a task for this WG or not? Carsten: Example yesterday: proposal for 2.06 response code "talk to me later". We could have a draft where the server leads the client to do something. Informational type of document. Brian Rosen: Your problem is not unique to OCF. PII is a general issue. Dave T: Correct. Ari: +1 to avoid forking. General mechanisms like this should be done at the IETF. Carsten: Contributors: Several (Erik, Christian, Zhen, Dave, Michael, Matthias?, … others?)
Carsten: Can already use URIs Dave T: OCF does not use URI for compactness. OCF has much more coming and would be load for the designated expert. Carsten: was reacting to the "x", which does not add any value. Dave T: right now vendors use point based because is more compact than using URI. Carsten: you save few characters, not big of a differences. Nothing prevents com.ibm.foo to register that. There's RFC that explains that using X-prefix is a bad idea Brian R: Bad idea to create different namespaces. OIC.temperature sensor is different than OTHER.temperature sensor. We shouldn't balkanize the namespace. If we have a processing problem let's fix the processing problem. Brian R: Lousy answer. Then we shouldn't use the registry if there is no solution. Carsten: (slide 210) "SHOULD provide a reference to where registrations can be found" it should be MUST and the org should provide interfaces or machine readable interfaces for usage. Dave T: OCF question is about resource types not interface types. Nr of RTs could be very large. If designated expert is willing to take that effort, OCF is fine, but could be a lot. Pete Resnick: Amplifying Brian's comments. Should try to avoid balkanizing the namespace. We should not create a protocol that decreases interoperability. Let's not do this. Alexander: Agree that we shouldn't allow registering anything. however OCF might go for something else if we do not help. What is their roadmap. Dave T: OCF is an org that standardized resource types, a long list. This is just a procedure for registration. Christian G: Currently no guidance for designated expert than see that it's a valid string Alexander: impression is that if we say no they'll continue duing as before (registering anyways). Michael Koster: agree on the problem. Here we need to make a choice if we are going to enable or not enable that. I am not proposing a solution but agree on a problem. Carsten: same problem in many registries. The expert does not work just by the letter but asks few questions. Is this needed? Have to be careful with pushback. Don't need to use codepoint because could use different than rt. Not winning much with pushback. Brian Rosen: Sympathize with designated expert problem. Can perhaps help. Maybe we need to rethink this process: anybody can come up with any name is maybe not the right solution. We need to come up with a better answer. Can help figuring out a better answer. Tim Carrey: you want to put the weight on the admin authority. Semantic interop is different issue. Support easing admin burden from expert. Encourage the group to think about this problem. Dave T: agree, the problem Carsten raised should not be underestimated. Could happen same than with URI schemes. Wikipedia list used to be where people "registered" schemes. Now took it to IANA. Dave Robin: BACNET had similar problems. We don't want to squash innovation, so we allow namespaces and multiple tags per registration. Also we had a big repository mapping. We did go through that process and the conclusion is that we let vendors use their own registry. Christian: had same discussion in the semantic interop ws Alexey Melnikov: Still trying to figure out potential actions, for example increasing the amount of people on the expert review team. Think about WG recommendation for the expert review. Should we come up with WG recommendation for expert review? I don't hear consensus to change the registration procedure. Need more discussion whether we want first come first serve or else. Carsten: good way forward is more expert review recommendations and high threshold prefix registration…. Alexey: hear some tension on "do not do it" (to Pete who shook his head).