Bridge EPP to RPP

[anewton1998]

From James Gould on the list:

3. Change " The RPP working group may however consider possibilities of mapping of data objects, operations and extensions from EPP to RPP for both clients and servers" to "The RRP working group may however consider possibility of bridging EPP to RPP for both clients and servers"
   a. The use of bridging is more generic and provides the possibility of reusing common elements across EPP and RRP

[pawel-kow]

From https://mailarchive.ietf.org/arch/msg/rpp/ABcz4Ga2mRWGUBO8uV9ip8VDnBU/

[PK] Maybe you may explain a bit more what practical different you see between the two? It may be that we have a different understanding of the subtle difference between the two so I would like to see a common understanding of those two terms before we decide to use this or the other.

[JG2] I see the usefulness of mapping the objects, operations, and extensions to help ensure functional equivalence, but I view the mapping as not as generic with other forms of bridging techniques that can be considered. RPP can be defined in two separate layers (RPP transport and RPP application packet protocol), where EPP with XML and RPP with JSON can ride on an RPP compliant transport layer. The broader “bridge” term would support this potential solution.

[PK2] if I understand your proposal right, that you want explicitly enable EPP payloads in the RPP protocol. I don't think I would be supportive of that as a requirement and also not on the charter. If it turns out in the architecture that it would be possible we may still reconsider, but I don't think RPP should be constraint by that. I think it would be just right to talk about mapping of equivalent of currently used EPP functionality in the charter.

[JG3] No, I want to define an RPP transport that is concerned with the mapping of provisioning commands to HTTP methods and mapping of provisioning objects to URL path segments and support an application packet protocol that can be either RPP and JSON or EPP and XML. From an EPP perspective, and EPP over REST (EoR) transport can be defined, which complies with an RFC 5730 transport and complies with the RPP transport. Thus, you have a bridge and not a mapping. I’m getting out ahead of the requirements myself with the solution space, but I want to ensure that the charter doesn’t disallow this type of ideation with language associated with mapping. Changing “mapping” to “bridge” will solve my concern of the charter embedding a specific solution.

I understand that and I don't think it should be put in the goals of RPP to explicitly enable it. It may happen that it would be still possible, but not a goal as such. In my eyes current charter proposal talking about mapping serves good the objectives.

[rpp-ietf]

Marteen, How about moving “The RPP working group may however consider possibilities of mapping of data objects, operations and extensions from EPP to RPP for both clients and servers” to the deliverable section as in: “The RPP working group will define the mapping of data objects, operations and extensions from EPP to RPP for both clients and servers” This could be combined with the deliverable of analyzing the existing EPP extensions (e.g., what is not supported, what is embedded in the standard object, and what remains an extension). This moves it from a goal to an activity that would be very useful. In taking a step back, below is my revised list of high-level goals for RPP, where I believe “RPP and EPP Overlap” is the target goal: 1. RPP and EPP Bridge - RPP has functional parity with EPP. 2. RPP as EPP Superset - RPP supports and extends the EPP features 3. RPP and EPP Overlap - RPP and EPP has an overlap of features, where some unused EPP features are removed 4. RPP Greenfield - RPP is built from the ground up without considering EPP interoperability Do you agree with “RPP and EPP Overlap” as the target goal? Thanks,

…

-- JG ***@***.*** James Gould Fellow Engineer ***@***.******@***.***> 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com<http://verisigninc.com/> From: Pawel Kowalik ***@***.***> Reply-To: SIDN/ietf-wg-rpp-charter ***@***.***> Date: Thursday, November 14, 2024 at 5:31 AM To: SIDN/ietf-wg-rpp-charter ***@***.***> Cc: Subscribed ***@***.***> Subject: [EXTERNAL] [rpp] Re: [SIDN/ietf-wg-rpp-charter] Bridge EPP to RPP (Issue #26) Caution: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. From https://mailarchive.ietf.org/arch/msg/rpp/ABcz4Ga2mRWGUBO8uV9ip8VDnBU/<https://secure-web.cisco.com/1KQPV7vh-Q32i8YDNwQJo8kPrm_XwhfB-hib8u7yfyLA4c9aT1Xh9ojR76puJ-6pxKHxMz8vyT7ePPDa7QdXlOGwOayjvw_52BnwhwRUvKuxK4hRrDkljMO2Nmg_0df3tR3sgaD9bUY8wprMXTxNGyalwXumRNMoF1y4bJosSlA3dG5YFIbF3jVcDHYr2pAUOmUzrMR_KliB2WGlgunaXBE0uh1EHbQlP4rTrDPLd7km0K9sGIAqKzhySwRmWbJLXEEXAt2gGPWjhQZqgTjPCNKf3hqMb5b59WZBKGbn-5Af1C-prJm_kz8vTQw9ovwzy/https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Frpp%2FABcz4Ga2mRWGUBO8uV9ip8VDnBU%2F> [PK] Maybe you may explain a bit more what practical different you see between the two? It may be that we have a different understanding of the subtle difference between the two so I would like to see a common understanding of those two terms before we decide to use this or the other. [JG2] I see the usefulness of mapping the objects, operations, and extensions to help ensure functional equivalence, but I view the mapping as not as generic with other forms of bridging techniques that can be considered. RPP can be defined in two separate layers (RPP transport and RPP application packet protocol), where EPP with XML and RPP with JSON can ride on an RPP compliant transport layer. The broader “bridge” term would support this potential solution. [PK2] if I understand your proposal right, that you want explicitly enable EPP payloads in the RPP protocol. I don't think I would be supportive of that as a requirement and also not on the charter. If it turns out in the architecture that it would be possible we may still reconsider, but I don't think RPP should be constraint by that. I think it would be just right to talk about mapping of equivalent of currently used EPP functionality in the charter. [JG3] No, I want to define an RPP transport that is concerned with the mapping of provisioning commands to HTTP methods and mapping of provisioning objects to URL path segments and support an application packet protocol that can be either RPP and JSON or EPP and XML. From an EPP perspective, and EPP over REST (EoR) transport can be defined, which complies with an RFC 5730 transport and complies with the RPP transport. Thus, you have a bridge and not a mapping. I’m getting out ahead of the requirements myself with the solution space, but I want to ensure that the charter doesn’t disallow this type of ideation with language associated with mapping. Changing “mapping” to “bridge” will solve my concern of the charter embedding a specific solution. I understand that and I don't think it should be put in the goals of RPP to explicitly enable it. It may happen that it would be still possible, but not a goal as such. In my eyes current charter proposal talking about mapping serves good the objectives. — Reply to this email directly, view it on GitHub<https://secure-web.cisco.com/1jesWiTFULXuMSJd-pZ3RgxFYinXCMo_0YmuCjn1ovwxo5C4kwEM16EuPtT6XNUSAmCJTIFsmc7bFGPIl-VBY5kpTzKA2DkAaNhVteP6QbVyIbH83rw36vSJq__T2MFzORdckll6YXLKXsl4DVGqSz-QfpWh9oG5GyXYXpoZswLLfNei9D-qjyz29nEWwVbOftFKecziHG5_y_BEh4s9daUpuLPmQK9hHQj7VV6E8dZXYmlHM0G3BbufqmJ7VycIcrcMLPaiktVHQWkClCCxBrFIKFCBHDXjpksx3IPFXJxbQwmxvi5lsyKYv2bKBrw-A/https%3A%2F%2Fgithub.com%2FSIDN%2Fietf-wg-rpp-charter%2Fissues%2F26%23issuecomment-2475978737>, or unsubscribe<https://secure-web.cisco.com/1PVIz9mNosYFkjcDSXGbtBEs9Xg5JwZeZkE1lVBUOK9CBBlth989he6A0Y9w8fr2-uE7xr5kYgvnXcpmfigOJfmYj4FFF0dDAMMJMpKfrxVMQSBKmkpLuyKCljeP-hB30nzeG60sRxqxcVNamIiruU58kPrlPXjak15LZ6t9jgyhZ4nsx56VA289cBCgigh0SqWmJvcnZkJisaZFwcj0MyEbP1aGwhJy97U8RtNP6qq2zkEuTaf_pdx2qg3e5E0KZISwySgSGZKMJqVXKl8SuwF2_x8fO6PDc2Qb-2HGLm8exzxXTcRyfi77JkMh9Esyt/https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FBM5CYNMILXJANWJ46MWRFFL2AR3S3AVCNFSM6AAAAABRUN3MO2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINZVHE3TQNZTG4>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[pawel-kow]

Hi James,

Yes, I guess we already agreed on RPP and EPP Overlap.

Please take a look at the most recent version of the charter if it is well reflected.

Kind Regards,
Pawel

[pawel-kow]

Adressed with #40