Re: [regext] [hrpc] Human Rights Review of draft-ietf-regext-verificationcode

[Adam Roach]

[speaking as an individual]

On 10/6/18 00:30, Adam Roach wrote:
I strongly support enumerating the concerns raised in the HRPC review 
as part of this document.


Since this came up during today's REGEXT meeting, I wanted to clarify 
something.


I made the above quoted statement assuming that no technical changes 
were going to be made to the document, and that the implications of the 
described mechanisms would be enumerated. It was a response to a handful 
of messages that seemed to be calling for no changes to the mechanism 
without evaluating the merit of any of the points raised by Gurshabad.


The current direction in the document (as shown by the -04 version) is 
to change the specification (e.g., removing the requirement to store 
verified data), and that seems even better. Given the direction things 
are going, I no longer see a need for an enumeration of concerns, as the 
actionable ones are being acted upon.


/a

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

Re: [regext] Picking XML namespaces

[Gould, James]

Patrick,

Thank you for your viewpoint on this.  I agree with you in theory but I 
disagree with you in practice. The EPP RFCs that exist today don't include any 
form of epp scoping, so the inflight extensions are simply following that 
pattern.  The request from IANA to scope the namespaces, that was first raised 
with draft-ietf-regext-launchphase, should be and is being incorporated.  
Examples include draft-ietf-regext-org, draft-ietf-regext-orgext, 
draft-ietf-regext-epp-fees, draft-ietf-regext-allocation-token, 
draft-ietf-regext-bundling-registration, and the new extensions, that now 
include the epp namespace scoping.  We do need to be careful to also consider 
the impact of making a change against following a new scheme.  In the case of 
draft-ietf-regext-launchphase that became RFC 8334, 
draft-ietf-regext-change-poll, and in the future 
draft-ietf-regext-verificationcode, the operational impact was and is too high 
in making the namespace change.  I believe that there needs to be a compelling 
reason to make the change, such as an IANA namespace conflict, to justify 
making the namespace change on extensions that will have operational impact.  I 
understand the method for supporting namespace changes on the client-side and 
the server-side, but the production and interoperability impacts need to be 
considered when incorporating a new scheme.
  
—
 
JG



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

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

Verisign.com  

On 11/6/18, 12:17 PM, "regext on behalf of Patrick Mevzek" 
 wrote:



On Mon, Nov 5, 2018, at 06:29, Gould, James wrote:
> Yes, there are Production systems in place that use this namespace.  
> Scoping the namespace at this stage would cause Production 
> interoperability issues.  Let me know if you need any additional 
> information.

I completely disagree with this reasoning, irrespective of the specific 
document as I would say the same thing for the same case.

This is only a draft, implementations are bound to change.
As a developer myself, I implemented a lot of drafts in their early 
versions, for "free" and it would have been the same thing for "just" 
namespaces changes. So I can totally understand the difficulty to change things 
at the last time, but then it is the game to play if we want global standards, 
their limits and edge cases appear when they are really implemented (hence the 
Implementation Status section in documents), and hence implementations are 
bound to need updates when the standard "matures"  and gets input from other 
parties.

Current deployments should not forbid making the document better and hence 
creating at the end a better standard for everyone.

If we do otherwise we just re-inforce something that I am seeing more and 
more which is converting this working group as a pure rubberstamping 
"authority"  were documents come already finished or close to finished or not 
really open to changes because it won't suit the original author.

It would be then too easy for anyone to come and then just refuse changes 
because it is already deployed as is.

Also, it was always sold that the greeting+login exchange enables client 
and server to autonegiotate extensions, including those that change the 
namespace (like the fee one with many different namespaces - even if just 
different on the version part - and many registries today exposing more than 
one).

Now what I can agree on is why setting the line at this document instead of 
any other one?
As soon as we have identified a problem regarding the namespaces used, I 
think all documents not yet being an RFC should be modified to adhere to the 
new convention. I see no sensible reason to say to do it for some but not 
others.

So my opinion is to change the namespace everywhere and not let any new 
extenson become an RFC without this change.

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

[regext] Milestones changed for regext WG

[IETF Secretariat]

Changed milestone "Submit for publication "Registry Fee Extension for EPP"",
resolved as "Done".

URL: https://datatracker.ietf.org/wg/regext/about/

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

Re: [regext] I-D Action: draft-ietf-regext-epp-fees-15.txt

[Patrick Mevzek]

On Sun, Nov 4, 2018, at 16:35, Roger D Carney wrote:
> A small updated was needed, implementers found the "standard" attribute 
> was not at the correct level in the commandDataType.

As expected and said previously, this late addition without any clear support 
from anyone except the initial requestor, will create interoperability problems.

I will not rehash the issue but I am not surprised and I will continue to think 
that this fee extension misses the goal of best compromise possible between 
features really needed by a common subset of actors and the complexity needed 
to encode all those features. 

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

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

Re: [regext] Picking XML namespaces

[Patrick Mevzek]

On Mon, Nov 5, 2018, at 06:29, Gould, James wrote:
> Yes, there are Production systems in place that use this namespace.  
> Scoping the namespace at this stage would cause Production 
> interoperability issues.  Let me know if you need any additional 
> information.

I completely disagree with this reasoning, irrespective of the specific 
document as I would say the same thing for the same case.

This is only a draft, implementations are bound to change.
As a developer myself, I implemented a lot of drafts in their early versions, 
for "free" and it would have been the same thing for "just" namespaces changes. 
So I can totally understand the difficulty to change things at the last time, 
but then it is the game to play if we want global standards, their limits and 
edge cases appear when they are really implemented (hence the Implementation 
Status section in documents), and hence implementations are bound to need 
updates when the standard "matures"  and gets input from other parties.

Current deployments should not forbid making the document better and hence 
creating at the end a better standard for everyone.

If we do otherwise we just re-inforce something that I am seeing more and more 
which is converting this working group as a pure rubberstamping "authority"  
were documents come already finished or close to finished or not really open to 
changes because it won't suit the original author.

It would be then too easy for anyone to come and then just refuse changes 
because it is already deployed as is.

Also, it was always sold that the greeting+login exchange enables client and 
server to autonegiotate extensions, including those that change the namespace 
(like the fee one with many different namespaces - even if just different on 
the version part - and many registries today exposing more than one).

Now what I can agree on is why setting the line at this document instead of any 
other one?
As soon as we have identified a problem regarding the namespaces used, I think 
all documents not yet being an RFC should be modified to adhere to the new 
convention. I see no sensible reason to say to do it for some but not others.

So my opinion is to change the namespace everywhere and not let any new 
extenson become an RFC without this change.

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

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

[regext] Jabber scribe and minutes taker for IETF103

[James Galvin]

As a reminder, please consider volunteering to be a Jabber scribe or 
minutes taker this afternoon.


Thanks,

Jim

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

Re: [regext] Benjamin Kaduk's Discuss on draft-ietf-regext-org-ext-09: (with DISCUSS and COMMENT)

[Linlin Zhou]

Hi James,
Thanks for your further suggestions. I'll include them in the updated version.

Regards,
Linlin


zhoulin...@cnnic.cn
 
From: Gould, James
Date: 2018-11-02 20:25
To: ka...@mit.edu; zhoulin...@cnnic.cn
CC: regext-cha...@ietf.org; pieter.vandepi...@dnsbelgium.be; i...@ietf.org; 
regext@ietf.org; draft-ietf-regext-org-...@ietf.org
Subject: Re: [regext] Benjamin Kaduk's Discuss on draft-ietf-regext-org-ext-09: 
(with DISCUSS and COMMENT)
I believe that we need to ensure that the 1-on-1 organization role mapping is 
consistently defined in the draft.  The definition of the "role" attribute, the 
possible value can be referenced in section 7.3, and the relationship between 
the organization id and the role should certainly be defined in section 3.1.  
The definition in 3.1 can be referenced in the create (4.2.1) and info (4.1.2), 
as in "One or more  elements that contain the identifier of the 
organization, as defined in [section 3.1]."  The update (4.2.5) is a little bit 
more complex to provide clarity on the behavior of the , 
 and the .  The following bullet could be removed from 
the update (4.2.5):
 
One or more  elements that contain the identifier of
the organization.  The "role" attribute is used to represent the
relationship that the organization has to the object.  See
Section 7.3 in [ID.draft-ietf-regext-org] for a list of values.
 
The reference to the  child elements and the expected behavior can 
be embedded under the definition of the , , and 
 elements, such as:
 
   o  An OPTIONAL  element that contains one or more  
elements, as defined in [section 3.1], that add non-existent organization roles 
to the object.  The  element MUST have a non-empty organization 
identifier value.  The server SHOULD validate that the  element role 
does not exist.  
 
   o  An OPTIONAL  element that contains one or more  
elements, as defined in [section 3.1], that remove organization roles from the 
object.  The  element MAY have an empty organization identifier 
value.  The server SHOULD validate the existence of the  element 
role and the organization identifier if provided.  
 
   o  An OPTIONAL  element that one or more  elements, 
as defined in [section 3.1], that change organization role identifiers for the 
object.  The existing organization identifier value will be replaced for the 
defined role.  The server SHOULD validate the existence of the  
element role. 
  
—
JG
 
 
 
James Gould
Distinguished Engineer
jgo...@verisign.com
 
703-948-3271
12061 Bluemont Way
Reston, VA 20190
 
Verisign.com  
 
On 11/1/18, 6:29 PM, "regext on behalf of Benjamin Kaduk" 
 wrote:
 
On Thu, Nov 01, 2018 at 11:28:10AM +0800, Linlin Zhou wrote:
> Dear Benjamin,
> I found that following sections may be the proper place to restrict the 
1-to-1 mapping. I think we can have restrictions in section 3.1 only or in 
3.1&4.2.1&4.2.5. I've not decided which one is better and hope to have others' 
suggestions.

I'd be happy to hear others' suggestions as well.  I don't have a strong
preference, but if forced to choose would put text in all three places.
(That is, others should feel free to choose "just section 3.1" and not
force me to choose, if they want.)

Thanks for putting together the proposals,

Benjamin

> 1. In section 3.1 Organization Identifier, add sentences at the end of 
this paragraph.
> A "role" attribute is used to represent the relationship that the 
organization has to the EPP object. Any given object MUST have at most one 
associated organization ID for any given role value.
> 
> 2. In section 4.2.1,
> One or more  elements that contain the identifier of the 
organization. The "role" attribute is used to represent the relationship that 
the organization has to the object. Any given object MUST have at most one 
associated organization ID for any given role value. See Section 7.3 in 
[ID.draft-ietf-regext-org] for a list of values.
> 
> 3. In section 4.2.5
> One or more  elements that contain the identifier of the 
organization. The "role" attribute is used to represent the relationship that 
the organization has to the object. Any given object MUST have at most one 
associated organization ID for any given role value. See Section 7.3 in 
[ID.draft-ietf-regext-org] for a list of values. 
> 
> If we have the restrictions, the 1-to-multiple mapping cases are not 
necessary to be specified in this document.
> 
> Regards,
> Linlin
> 
> 
> Linlin Zhou
>  
> From: Benjamin Kaduk
> Date: 2018-10-31 20:43
> To: Linlin Zhou
> CC: regext-chairs; Pieter Vandepitte; iesg; regext; 
draft-ietf-regext-org-ext
> Subject: Re: [regext] Benjamin Kaduk's Discuss on 
draft-ietf-regext-org-ext-09: (with DISCUSS and COMMENT)
> Dear Linlin,
>  
> On Wed, Oct 31, 2018 at 02:19:45PM +0800, Linlin Zhou wrote:
> > Dear Benjamin,
> > Thanks for