[regext] Ideas to address the privacy implication of reverse search draft

[Ali Hussain]

Hi All,

It wa  interesting to see the interest during REGEXT IETF 109 meeting call
to address the the privacy aspects of draft
(draft-ietf-regext-rdap-reverse-search).


So far my idea to improve the reverse search to first make the JSON object
for the required level of privacy critical data. Based on the tag the
partial response suppresses the privacy part of responses by encoding and
in order to decode it, it must present an identity to federated access
control.

I am also reviewing the hrpc draft to bring some valuable input form their
guidance.

Please let me know what you think and is anyone else interested to work on
this?

Thanks,

Regards,
Ali Hussain
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] draft-ietf-regext-unhandled-namespaces Intellectual Property Disclosure Confirmation Request

[Smith, David - Dulles]

Thank you, Jim.

@Martin: have you been able to confirm the same? Sorry if I missed that you 
have done so.

From: James Gould 
Date: Tuesday, November 24, 2020 at 12:51 PM
To: "Smith, David - Dulles" , "martin.casan...@switch.ch" 
, "regext@ietf.org" 
Subject: Re: draft-ietf-regext-unhandled-namespaces Intellectual Property 
Disclosure Confirmation Request

I confirm that any and all appropriate IPR disclosures required for full 
conformance with the provisions of BCP 78 and BCP 79 have already been filed 
for draft-ietf-regext-unhandled-namespaces.

--

JG

[cid:image001.png@01D6C97C.55AD3270]

James Gould
Fellow Engineer
jgo...@verisign.com

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com

From: David Smith 
Date: Tuesday, November 24, 2020 at 11:41 AM
To: James Gould , "martin.casan...@switch.ch" 
, "regext@ietf.org" 
Subject: draft-ietf-regext-unhandled-namespaces Intellectual Property 
Disclosure Confirmation Request

Hi Jim Gould and Martin Casanova –

As the document shepherd for draft-ietf-regext-unhandled-namespaces, I need to 
ask whether each of you (as draft authors) has confirmed that "any and all 
appropriate IPR disclosures required for full conformance with the provisions 
of BCP 78 and BCP 79 have already been filed."

Please do confirm or disconfirm by replying here and including the mailing list 
regext@ietf.org on the reply.

Thanks!

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

[regext] Shepherd's nits on draft-ietf-regext-unhandled-namespaces

[Smith, David - Dulles]

Hi –

As the document shepherd for draft-ietf-regext-unhandled-namespaces, I reviewed 
the text of the draft and had the following feedback for consideration. It’s 
grouped by document section or page number.

Abstract
"server tof determine" -> "tof" typo

2. Unhandled Namespaces

Original:
"The unhandled namespaces problem exists when the server has information, that 
it needs to return to the client, that is not supported by the client"
Proposal:
"The unhandled namespaces problem exists when the server has information that 
it needs to return to the client but the namespace of the information is not 
supported by the client"

3.  Use of EPP  for Unhandled Namespace Data

Original:
"caused a server error condition, and the  element"
Proposal:
"caused a server error condition and the  element"

Original:
"When a server has data to return to the client, that the client"
Proposal:
"When a server has data to return to the client that the client"

[Page 8]
The example includes a server response where the  child elements are 
not indented but should be.

4.  Signaling Client and Server Support

Original:
"in the server's Greeting extension services, can expect"
Proposal:
"in the server's Greeting extension services can expect"

Original:
"in the client's  Command extension services, can expect"
Proposal:
"in the client's  Command extension services can expect"

5.  Usage with General EPP Responses

Original:
"MAY include it under in the "
Proposal:
"MAY include it under the "

7.1.  Client Implementation Considerations

Original:
"Ensure that the login services is accurate with what is supported by the 
client."
Proposal:
"Ensure that the client presents the complete set of what it supports when 
presenting its login services"

Original:
"The unhandled namespace can be implemented"
Proposal:
"The unhandled namespace should be implemented"

7.2.  Server Implementation Considerations

Original:
"the server should consider the following"
Proposal:
"the server should consider doing the following"



___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

[regext] Protocol Action: 'Registration Data Access Protocol (RDAP) Query Parameters for Result Sorting and Paging' to Proposed Standard (draft-ietf-regext-rdap-sorting-and-paging-20.txt)

[The IESG]

The IESG has approved the following document:
- 'Registration Data Access Protocol (RDAP) Query Parameters for Result
   Sorting and Paging'
  (draft-ietf-regext-rdap-sorting-and-paging-20.txt) as Proposed Standard

This document is the product of the Registration Protocols Extensions Working
Group.

The IESG contact persons are Murray Kucherawy and Barry Leiba.

A URL of this Internet Draft is:
https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-sorting-and-paging/





Technical Summary

This document describes RDAP query extensions that allow clients to
specify their preferences for sorting and paging result sets. This helps
clients to find relevant results more easily, as well as improving server
response times and reducing bandwidth requirements.


Working Group Summary

This document was posted to the WG back in mid-2017, and has been
presented at IETF 100 and 103-106, as well as at the Registration
Operations Workshop (#6).  There was nothing unusual process-wise, and no
issues with consensus or similar.


Document Quality

There are two proof-of-concept implementations, and there were a number
of reviews from within the group.  No expert review was required.


Personnel

Document Shepherd: Tom Harrison
Responsible AD: Barry Leiba

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext