Re: [regext] DOODLE: select your documents

[Patrick Mevzek]

Hello Alexander,

On Thu, Jan 3, 2019, at 03:25, Alexander Mayrhofer wrote:
> Jim, 
> 
> thanks for posting that - i've made my choices. 
> 
> 

For the record, I share most if not all of your rant Alexander.

1) I am sad to see this working group and the IETF being a rubberstamp for 
documents discussed elsewhere and coming here explicitely as stated just to get 
an RFC number.
This is wrong on so many levels and could even be seen as an abuse of IETF.
I do not think the working group should put time and energy on those documents. 
In most cases they can as well be an individual submission or just stay as a 
specification added
to the EPP Extension registry.
If people decided to work on them in other venues, then they should just finish 
"standardization" of them in those other venues, switching to the IETF at the 
last minute just for an RFC number is certainly not the expected way to work.

The aim of the working group in my mind is to try defining extension that works 
for
the widest use cases possible accross many registrars and registries. The 
community is not so big so splitting work in many venues even lowers the chance 
the results will have enough reviews to make them as generic and globally 
useful as possible.

Like Alexander stated, the impact of each specification (does it concern one 
specific case or is it useful for all EPP servers in the world) could or should 
be taken into account when deciding to work on X instead of Y.

Otherwise we get only a very thin short time frame gain of having RFC for 
numerous "standardized" extensions where no real consensus will exist on them, 
some will overlap or even contradict themselves which will in the long term 
make the current situation regarding deployed extensions on servers even more 
complex that it is nowadays (and it is complex enough), hence making registrars 
even more complicated which in turn constrains registries to not be able to 
easily run new services because registrars will not implement them, etc.

2) I would have much prefered seeing people coming on this exact mailing-list 
and stating that they will support such and such documents by promising to work 
on them (reviewing, implementing, etc.) instead of an anonymous poll done on a 
remote site, whose results are difficult to interpret (is it interest in 
something being done? willingness to work on it? just showing that is seems to 
be important without any real interest in it? etc.). That would have shown real 
community support for some documents and provide a clear proof of interests 
later on for shepherd reviews and IETF-wide LC.

For all these reasons I voluntarily did not participate in this polling, even 
if I clearly have my opinion on which documents are most useful to work on than 
others and which should get the WG attention or not.

That is the end of my rant.

-- 
  Patrick Mevzek
  p...@dotandco.com

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

Re: [regext] DOODLE: select your documents

[James Galvin]

This is the final reminder.  The poll will close today.

With 20 participants indicating preferences, I can say that RDAP is the 
clear winner.  More folks care about RDAP options than about 
registry-registrar options.


Here are the top 5 so far (highest to lowest) based on raw numbers:

Federated Authentication for RDAP
RDAP Partial Response
RDAP Reverse Search
RDAP Sorting and Paging
Login Security

The first choice is clear.  There is not much difference in the numbers 
past that point.


Working group members are invited to look at the raw entries and offer 
commentary about what it shows.


The co-Chairs will make a proposal for consideration early next week.

Jim




On 10 Jan 2019, at 7:37, James Galvin wrote:


Thanks to all those who have indicated their document preferences.

This is a reminder we will close the poll tomorrow, so if you 
haven’t indicated your preferences please do so.


Currently, there is a small set at the top of the list.  More than 5, 
although there is a pretty clear top two.


Thanks again,

Jim



On 21 Dec 2018, at 11:13, James Galvin wrote:

Please take the time to select the documents you support for 
advancement in this working group.


https://doodle.com/poll/6nyguby3yr8dx9cp

Please select from 1-5 documents.

If you click once in the box a green check mark will appear.  Use 
this to indicate support for a document.  If you click twice in the 
box a yellow check mark in parentheses will appear.  You may use the 
yellow check mark to indicate support that is a lower priority than a 
green check mark.


For your convenience I have included the list of documents and their 
links below.


This selection process will remain open for 3 weeks, until 11 January 
2019.


Enjoy your holiday season!  See you all next year!

Jim


DOCUMENTS TO CONSIDER

Registry Reporting Repository
https://datatracker.ietf.org/doc/draft-mcpherson-sattler-registry-reporting-repo/

Registry Reporting Structure
https://datatracker.ietf.org/doc/draft-mcpherson-sattler-registry-report-structure/

Domain Fee Report
https://datatracker.ietf.org/doc/draft-sattler-registry-domain-fee-report/

Registry Transaction Report
https://datatracker.ietf.org/doc/draft-mcpherson-sattler-ry-transaction-report/

Registry Domain Inventory Report
https://datatracker.ietf.org/doc/draft-sattler-registry-domain-inventory-report/

Registry Domain Drop Report
https://datatracker.ietf.org/doc/draft-sattler-registry-domain-drop-report

Registry Unavailable Domain Report
https://datatracker.ietf.org/doc/draft-sattler-registry-unavailable-domain-report/

Registry Maintenance Notifications
https://datatracker.ietf.org/doc/draft-sattler-epp-registry-maintenance/

Unhandled Namespaces
https://tools.ietf.org/html/draft-gould-casanova-regext-unhandled-namespaces

Data Set File Format
https://datatracker.ietf.org/doc/draft-gould-regext-dataset/

Login Security
https://datatracker.ietf.org/doc/draft-gould-regext-login-security/

Federated Authentication for RDAP
https://datatracker.ietf.org/doc/draft-hollenbeck-regext-rdap-openid/

RDAP Partial Response
https://datatracker.ietf.org/doc/draft-loffredo-regext-rdap-partial-response/

RDAP Search
https://datatracker.ietf.org/doc/draft-fregly-regext-rdap-search-regex/

RDAP Reverse Search
https://datatracker.ietf.org/doc/draft-loffredo-regext-rdap-reverse-search/

RDAP Sorting and Paging
https://datatracker.ietf.org/doc/draft-loffredo-regext-rdap-sorting-and-paging/

Registry Data Escrow Specification
https://datatracker.ietf.org/doc/draft-arias-noguchi-registry-data-escrow/

Domain Name Registration Data (DNRD) Objects Mapping
https://datatracker.ietf.org/doc/draft-arias-noguchi-dnrd-objects-mapping/

Third Party DNS Operator to Registrar/Registry
https://datatracker.ietf.org/doc/draft-ietf-regext-dnsoperator-to-rrr-protocol/

Validate
https://datatracker.ietf.org/doc/draft-ietf-regext-validate/

Verification Code
https://datatracker.ietf.org/doc/draft-ietf-regext-verificationcode/


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

Re: [regext] Minor comment on draft-gould-regext-login-security-02

[Gould, James]

Patrick,

Thank you for implementing draft-gould-regext-login-security and the feedback.  
I provide responses to your feedback below prefixed with "JG - ".  
  
—
 
JG



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

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

Verisign.com  

On 1/11/19, 2:12 AM, "regext on behalf of Patrick Mevzek" 
 wrote:

Dear James and Matthew,

A minor point while implementing it (finished, will announce it soon).

If a new "long" password is presented, it is exchanged in the 
node.

However for events, among the list of possible values for type you have: 
newPw

I see no reason for the different casing.

I recommend that the type value is also newPW or, to be more in line with 
other
values to just spell it out in full, hence "newPassword".

In fact I have found out one instance of

for the XML node, so maybe a leftover of a previous change.
You may want to double check all examples/quotes of the node name to have 
the proper casing.
 
JG - Thank you for finding the inconsistency to the case of the 
 element in the extension.  The goal is to match the case of 
the  element in RFC 5730, so I'll be sure to consistently reference 
"newPW" throughout in the next version of the draft.  
   
Also since all 3 nodes are optional under loginSec you may wish to specify 
that the extension should be sent only if at least one of the node is present 
beneath it.
Or what the server should reply if it gets only an empty root node.

JG - I agree some text would be helpful here.  I would anticipate that even if 
there was an empty  element, the server would only process 
the elements passed, so the server would do nothing with the empty element.  
I'll take a shot with some text in the next version of the draft.

(and on a more philosophical level, I feel userAgent should not be defined 
in this extension because it has nothing to do with passwords and could be 
useful just be itself; it is useless however to create an extension just for it 
so I can understand why putting it there, but it is still bundling things 
together that are not related)

JG - The Login Security Extension goes beyond passwords and relates to security 
in general.  The userAgent helps identify current and future security events 
that can be included in the login response.  

And maybe provide some advice about downgrade, what about the following 
chain of events:
- change of password using loginsec:newPW for a long password
- but then change back to short password using pure newPW without the 
loginSec part.

Allowed? Recommended?
 
JG - Yes, it would be allowed by the extension, but may not be allowed by 
server policy.  The  element is only required if the new 
password is longer than the RFC 5730 maximum of 16 characters.  The same holds 
true for the  element.  I recommend that the client increase 
instead of decrease the strength of the passwords, but there is nothing in the 
extension that would disallow it.   

   
-- 
  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

Re: [regext] Minor comment on draft-gould-regext-login-security-02

[Hollenbeck, Scott]

> -Original Message-
> From: regext  On Behalf Of Gould, James
> Sent: Friday, January 11, 2019 1:21 PM
> To: p...@dotandco.com; regext@ietf.org
> Subject: [EXTERNAL] Re: [regext] Minor comment on draft-gould-regext-
> login-security-02
>
> Patrick,
>
> Thank you for implementing draft-gould-regext-login-security and the
> feedback.  I provide responses to your feedback below prefixed with "JG - ".
>
> —
>
> JG
>
>
>
> James Gould
> Distinguished Engineer
> jgo...@verisign.com
>
> 703-948-3271
> 12061 Bluemont Way
> Reston, VA 20190
>
> Verisign.com 
>
> On 1/11/19, 2:12 AM, "regext on behalf of Patrick Mevzek"  boun...@ietf.org on behalf of p...@dotandco.com> wrote:
>
> Dear James and Matthew,
>
> A minor point while implementing it (finished, will announce it soon).
>
> If a new "long" password is presented, it is exchanged in the 
> node.
>
> However for events, among the list of possible values for type you have:
> newPw
>
> I see no reason for the different casing.
>
> I recommend that the type value is also newPW or, to be more in line with
> other
> values to just spell it out in full, hence "newPassword".
>
> In fact I have found out one instance of
> 
> for the XML node, so maybe a leftover of a previous change.
> You may want to double check all examples/quotes of the node name to
> have the proper casing.
>
> JG - Thank you for finding the inconsistency to the case of the
>  element in the extension.  The goal is to match the case
> of the  element in RFC 5730, so I'll be sure to consistently
> reference "newPW" throughout in the next version of the draft.
>
> Also since all 3 nodes are optional under loginSec you may wish to specify
> that the extension should be sent only if at least one of the node is present
> beneath it.
> Or what the server should reply if it gets only an empty root node.
>
> JG - I agree some text would be helpful here.  I would anticipate that even if
> there was an empty  element, the server would only
> process the elements passed, so the server would do nothing with the
> empty element.  I'll take a shot with some text in the next version of the
> draft.
>
> (and on a more philosophical level, I feel userAgent should not be defined
> in this extension because it has nothing to do with passwords and could be
> useful just be itself; it is useless however to create an extension just for 
> it so
> I can understand why putting it there, but it is still bundling things 
> together
> that are not related)
>
> JG - The Login Security Extension goes beyond passwords and relates to
> security in general.  The userAgent helps identify current and future security
> events that can be included in the login response.
>
> And maybe provide some advice about downgrade, what about the
> following chain of events:
> - change of password using loginsec:newPW for a long password
> - but then change back to short password using pure newPW without the
> loginSec part.
>
> Allowed? Recommended?
>
> JG - Yes, it would be allowed by the extension, but may not be allowed by
> server policy.  The  element is only required if the new
> password is longer than the RFC 5730 maximum of 16 characters.  The same
> holds true for the  element.  I recommend that the client
> increase instead of decrease the strength of the passwords, but there is
> nothing in the extension that would disallow it.

Jim, that sounds like it's worth addressing in the Security Considerations 
section of the document.

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

Re: [regext] Minor comment on draft-gould-regext-login-security-02

[Gould, James]

Scott,

I'll take a shot at adding some text to the Security Considerations section for 
this.  
  
—
 
JG



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

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

Verisign.com  

On 1/11/19, 1:52 PM, "Hollenbeck, Scott" 
 wrote:

> And maybe provide some advice about downgrade, what about the
>following chain of events:
> - change of password using loginsec:newPW for a long password
> - but then change back to short password using pure newPW without the
>loginSec part.
>
> Allowed? Recommended?
>
>JG - Yes, it would be allowed by the extension, but may not be allowed by
>server policy.  The  element is only required if the new
>password is longer than the RFC 5730 maximum of 16 characters.  The same
>holds true for the  element.  I recommend that the client
>increase instead of decrease the strength of the passwords, but there is
>nothing in the extension that would disallow it.

Jim, that sounds like it's worth addressing in the Security Considerations 
section of the document.



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

Re: [regext] Comments about draft-gould-casanova-regext-unhandled-namespaces

[Gould, James]

Patrick,

I provide responses to your feedback below, prefixed with "JG - ".
  
—
 
JG



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

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

Verisign.com  

On 1/11/19, 2:38 AM, "regext on behalf of Patrick Mevzek" 
 wrote:



On Sun, Jan 6, 2019, at 23:02, Patrick Mevzek wrote:
> Hello James and Martin,

Thanks for your attention and comments to my email.
I see that we are in disagreement, so I think it is not useful for me to go 
again over all points.

My opinion still remains that at this stage the draft abuses RFC 5730 too 
much and needlessly because I believe there are other options that makes it 
more in line with RFC 5730 spirit.

JG - We will agree to disagree on this one.

In fact I believe that in its current form it will create an 
interoperability problem
and hence it lowers its chance to be implemented by a huge range of 
registrars.


It is not a problem for registries of course because on server side it is 
just the matter
of creating some new nodes at some location in the frame.

But a registrar has to handle many different EPP servers, some will have 
implemented this extension, some not.

And hence why it does create an interoperability problem?
Because:
1) if this extension is not explicitely announced at greeting time by the 
server
(something you seem to be very much against)

JG - How does announcing something in the greeting help out here, which at most 
would be a single namespace?  By including a namespace in the greeting, what is 
expected if the client does not include that namespace in the login services?  
This represents a chicken and egg situation.  The namespace does not define 
exactly which extensions and for what type of responses the server will apply 
draft-gould-casanova-regext-unhandled-namespaces to.  That is why the policy of 
the implementation of draft-gould-casanova-regext-unhandled-namespaces is best 
suited in a policy extension of the Registry Mapping, where policy information 
can be made much clearer.  We discussed creating an extension to communicate 
the unhandled namespaces issue at the REGEXT meeting, which was quickly 
eliminated because of the chicken and egg situation.  There is a further issue 
that the BCP of draft-gould-casanova-regext-unhandled-namespaces does not fit 
any type of existing EPP extension (object, command / response, protocol) that 
would be communicated in the greeting.  I don't believe the EPP greeting should 
be used to communicate a BCP or a policy.  

2) and if you continue to use extValue/value + reason, the latter being for 
human consumption but you add a format in it with a SHOULD and opening problem 
with the lang attribute

JG - Why is providing a recommended formatted human readable reason in the 
draft considered an interoperability problem?  Having a consistent reason for 
the inclusion of the  element will provide clarity and should help 
with interoperability.  If the lang attribute is causing concern, text can be 
added to also recommend using the default "lang" attribute value of "en".  
Since the draft has this defined as a SHOULD, a server implementer can choose 
to use a different reason in a different language. 

3) THEN a client (registrar) CAN NOT depend on the reason content to find 
out about the namespace concerned (because the reason content is only a SHOULD 
and the specification does not deal with a lang different than "en" ... all 
points showing again that you should not abuse a human targeted field to put 
machine readable data in it)
so it can instead just parse the content of  and take the first 
namespace it sees there
BUT it has no idea if the content of  is something coming from your 
extension or something completely different (coming from the initial definition 
of  in RFC5730)
so it will need to use heuristics instead of relying on determinism, or 
just drop all of it and not caring at all.
   
JG - This reason is meant by RFC 5730 and by 
draft-gould-casanova-regext-unhandled-namespaces to be human readable and is 
not meant in any way for a software client to parse it and depend on it.  There 
is absolutely nothing wrong with recommending a more consistent and more human 
readable reason in the draft.
 
It is important for a client to understand if what comes back in 
value/extValue is due to what it has sent (original description of the fields 
in RFC 5730) or something completely different as in your extension. In its 
current form your extension leaves no way for a registrar to know without doubt 
in which case it is.

I think that creating this interoperability problem just adds one more 
problem on top of the problem of handling unknown namespaces.

Hence I will not be in favor of this extension going forward in its current 
shape.

JG - I don't view the points that you raised a