Re: [regext] Poll messages with unhandled namespaces (was Re: I-D Action: draft-ietf-regext-change-poll-07.txt)

[Pieter Vandepitte]

I agree: move on, and make this discussion a new work item for the group.

It was an interesting discussion by the way... 

My opinion: 

First of all, I don't know about real world examples of issues concerning 
unsupported extensions by one of our registrars. When we introduce new 
extensions, or update existing ones, this is all communicated long in advance 
to all of our registrars so they can prepare the change. They have plenty of 
time to implement the extensions, and if they don't implement them, I guess 
they just ignore it (non-validating clients). There's no such thing as a client 
which all of a sudden must support or handle new extensions. 

Now to answer the questions:

1. Do you believe that it is protocol compliant for the server to return 
something that the client did not explicitly include in the login services?

No. As Postel said: "be conservative in what you do". The client says it does 
not understand it, so be kind and don't return it.

2. The purpose of the server's greeting service and the client's login 
services: 

It's not a negotiate. It's informational, and in case of the login svcs it's a 
kind request to only "talk the languages" of the supported extensions. Should a 
server return an error when it receives a request containing extensions it does 
understand, but which are not mentioned by the client? No, even not for 
extensions it does not understand.

3. Validating clients: clients should be permissive in what they accept. A 
client must interpret the server's response as good as possible (i.e. ignoring 
XSD violations, use of non-supported schema's, ...).

What about poll responses potentially containing extensions not supported by 
the client? Because of (3) that should not be a problem, but since in my 
opinion a server should be conservative (to be able to serve both validating 
and non-validating clients), it should send the response in another way. This 
is in my opinion a task for the working group. (Top of mind suggestion: encode 
part of the response which is not understood as a CDATA block)

kind regards

Pieter




> On 04 May 2018, at 20:27, Roger D Carney  wrote:
> 
> Good Afternoon,
>  
> +1.
>  
> We agree that that we should move forward with the current 
> draft-ietf-regext-change-poll draft and move this discussion along another 
> path.
>  
>  
> Thanks
> Roger
>  
>  
> From: regext [mailto:regext-boun...@ietf.org] On Behalf Of Gould, James
> Sent: Friday, May 04, 2018 9:16 AM
> To: James Galvin 
> Cc: Patrick Mevzek ; regext@ietf.org
> Subject: Re: [regext] Poll messages with unhandled namespaces (was Re: I-D 
> Action: draft-ietf-regext-change-poll-07.txt)
>  
> Jim,
>  
> My recommendation is to move forward with draft-ietf-regext-change-poll and 
> to leave the EPP server sending unsupported responses (mapping extension and 
> / or command response extensions) to a client based on the login services up 
> to a separate draft.  
>  
> This comes down to the interpretation of how the server should handle the 
> login services of the client in creating responses.  EPP extensions like the 
> DNSSEC extension (RFC 5910) leverages the login services in the migration 
> from RFC 4310 to RFC 5910, since the info response may include the DNSSEC 
> extension if there is DNSSEC data.  The inclusion of the DNSSEC extension and 
> the version of the DNSSEC extension is based on the login services.  Similar 
> functionality exists within draft-ietf-regext-epp-fees in determining if and 
> which version of the extension to return to the client.  Poll messages are 
> unique since they are inserted ahead of time by the server without knowledge 
> of what the client does support, and therefore runs the risk of coming across 
> a message that the client does not support based on the login services.  
> Clients may or may not be able to handle the parsing and unmarshalling of 
> unsupported extensions sent by the server.  For poll messaging this is of 
> particular interest, since a client may have an issue acknowledging the 
> unsupported poll messages to get to the rest of the messages in the queue.  
> This would represent a poison message in the poll queue. 
>  
> Based on the thread, there are separate thoughts related to whether it is 
> fine for the server to send a response that contains an extension that was 
> not included in the client’s login services.  I believe that the greeting 
> services and the login services are used to negotiate the set of extensions 
> that client are server can use.  What should the EPP server do with 
> unsupported extensions in any EPP response and with poll message EPP 
> responses in particular?  This is a broader topic than 
> draft-ietf-regext-change-poll, so I recommend that we don’t attempt to solve 
> the problem specifically for draft-ietf-regext-change-poll but more 
> generically across all of the extensions in a separate draft.  
>  
>  
> —
>  
> JG
> 
> 

[regext] Final review of draft-ietf-regext-org-06

[Pieter Vandepitte]

Hi Linlin,

I did a review with a magnifying glass. Some things should really be fixed (or 
rather MUST be fixed), some others are opinionated.

I'm preparing a review of the draft-ietf-regext-org-ext-06 too, but that's for 
tomorrow

===
 
> 3.1 .  
> Organization Identifier
> All EPP organizations are identified by a server-unique identifier.
>Organization identifiers are character strings with a specific
>minimum length, a specified maximum length, and a specified format.
>Organization identifiers use the "clIDType" client identifier syntax
>described in [RFC5730 ].  Its 
> corresponding element is .
 
I would use "specified" instead of "specific". This is more in line with other 
RFCs (domain and contact). It's also a specific length, format etc… but the 
emphasis is on the fact that it's all in the specs (hence specified).

=== 
 
> 3.2 .  
> Organization Roles
> The organization roles are used to represent the relationship an
>organization would have.  Its corresponding element is .
 
⇒ MUST instead of would

An organization object MUST always have at least one associated role. Roles can 
be set only by the client that
Sponsors an organization object. A client can change the role of an 
organization object using the EPP  command.
 
===

> 3.2.1 .  
> Role Type
> An organization would support a list of roles.  See Section 7.3 
>  for a
>list of values.  Its corresponding element is .

I think the sentence is wrong. You should talk about role type, not about "list 
of roles"

An organization role MUST have a type. […]

===
 
> 3.2.2 .  
> Role Status
> A role of an organization object would have its own statuses.  Its
>corresponding element is .  The values of the role status
>are defined in Section 3.5 
> .
 
I'm not sure if "would" is the best word to use here.

An organization role MAY have a status. […]
 
===
 
> 3.4 .  
> Organization Status Values

 
I think you forgot to specify that

"linked" status MUST NOT be combined with either "clientLinkProhibited" or 
"serverLinkProhibited" status.
 
Or is this in case you want to block linking while there are still links? If 
so, it's useful to specify this:

A client or server MAY combine linked with either clientLinkProhibited or 
serverLinkProhibited if new links must be prohibited [...]

=== 
 
> 3.5 .  Role 
> Status Values
>  
> […]
>  
> o  ok: This is the normal status value for an role that has no
>   pending operations or prohibitions.  This value is set and removed
>   by the server as other status values are added or removed.
 
⇒ There are no pending statuses for role statuses, so remove that part
 
Also here, I think you forgot to specify that

"linked" status MUST NOT be combined with either "clientLinkProhibited" or 
"serverLinkedProhibited" status.
 
===

> 4.1.2 .  
> EPP  Command

 
Should we mention what happens in case the querying client is not the 
sponsoring client, or is too much policy?

And a bit lower:
 
> […]
>When an  command has been processed successfully, the EPP
> element MUST contain a child  element that
>identifies the organization namespace.  The  element
>contains the following child elements:
> […]
>o  Zero or more  elements that contains the operational
>   status of the organization, as defined in Section 3.4 
> .
 
⇒ this conflicts with the XML schema and 3.4, which states:
   An organization object MUST always have at least one associated
   status value.  The default value is "ok".

=== 

>  4.2.5 . 
> EPP  Command
> [...]
> Zero or more  elements that contains the role type, role
>   statuses and optional role id of the organization

In my opinion the draft is still vague about which role sub-element of role is 
used for matching the role to be removed (I guess it is the role type, as it is 
the only required element). I would mention that:

E.g. in secDNS it is mentioned very explicit;
 
  The  element is part of the Key Data Interface and
  is used to uniquely define the key data to be removed, by using
  all four elements -- , , , and  -- that are guaranteed to be unique.
  There can be more than one DS record created for each key, so
  removing a key could 

Re: [regext] IETF 101 minutes, and discussions not happening on this mailing-list

[Pieter Vandepitte]

Hi Patrick,

> 
>> Registry Mapping, Roger Carney
>> Open question on boot strap for registry mapping
>> Discussion about how to distribute the data and if it is public at all.
>> Question if this data should be in EPP, RDAP or something else.
>> Next step: make a draft, adaption
> 
> Why is this not done and discussed on this mailing-list but only during face 
> to
> face meetings and over the phone? I think this excludes some participants and
> also lacks any kind of material minutes and searching capabilities.

I think nobody just took the lead to start the discussion in the mailing list, 
yet? We should not wait for the chairs to start a thread, so let's get started.

> 
>> James Galvin mentions that ICANN has a tech ops groups with many
>> registrars present.  This group will send documents for
>> standardization to the Regext WG.  Intense discussion about process
>> and involvement. To get standards people need to participate.
> 
> I find that way to work quite worrisome. I do not think this working group
> should be rubber stamping documents elaborated elsewhere, even under the best
> assumptions for everyone, and even if "everywhere" is also populated by many
> people hanging here.
> It may be sad that not too many or not enough registrars are on this 
> mailing-list,
> but instead of having the discussions elsewhere, why not encouraging them to 
> come
> here? Each registry should do that for its registrars.
> 
> If I take the latest (only?) example of this, it is the draft about registry
> message on maintenance. There was almost no discussion of it here, I was the 
> only
> one to convey some comments/questions that were not acknowledged nor adressed 
> in any way. It would find it very strange to see it come back and asking for 
> the working group adoption.

I share your opinion. I think it's a good idea to offload the ICANN policy 
stuff to the techops list, and I think the techops list is a valuable input for 
regext, but there's little enthusiasm to think about the specs. We need more 
horsepower, especially from the registrars who benefit most.


Pieter




signature.asc
Description: Message signed with OpenPGP using GPGMail
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] Final review of draft-ietf-regext-org-06

[Pieter Vandepitte]

Hi Linlin, James,

One thing that is still not very clear to me. (and the draft offers me no 
answer)

Suppose a new organization O with 2 roles (R1 and R2). Status of the 
organization is 'ok', status of the roles are both 'ok'. Right?
Then I link a domain to O via R1. Is it right that status of O is 'linked', 
status of R1 is 'linked' and status of R2 is ok?

kind regards

Pieter




> On 22 May 2018, at 04:49, Linlin Zhou <zhoulin...@cnnic.cn> wrote:
> 
> Dear Pieter,
> Please find my feedbacks below on other comments besides James' feedbacks. 
> Thanks for your review. I am preparing the update.
> 
> Regards,
> Linlin
> zhoulin...@cnnic.cn <mailto:zhoulin...@cnnic.cn>
> 
> From: Pieter Vandepitte <mailto:pieter.vandepi...@dnsbelgium.be>
> Date: 2018-05-20 04:29
> To: regext <mailto:regext@ietf.org>
> Subject: [regext] Final review of draft-ietf-regext-org-06
> Hi Linlin,
> 
> I did a review with a magnifying glass. Some things should really be fixed 
> (or rather MUST be fixed), some others are opinionated.
> 
> I'm preparing a review of the draft-ietf-regext-org-ext-06 too, but that's 
> for tomorrow
> 
> ===
> 
>> 3.1 <https://tools.ietf.org/html/draft-ietf-regext-org-06#section-3.1>.  
>> Organization Identifier
>> All EPP organizations are identified by a server-unique identifier.
>>Organization identifiers are character strings with a specific
>>minimum length, a specified maximum length, and a specified format.
>>Organization identifiers use the "clIDType" client identifier syntax
>>described in [RFC5730 <https://tools.ietf.org/html/rfc5730>].  Its 
>> corresponding element is .
> 
> I would use "specified" instead of "specific". This is more in line with 
> other RFCs (domain and contact). It's also a specific length, format etc… but 
> the emphasis is on the fact that it's all in the specs (hence specified).
> 
> [Linlin] Changed to "with a specified minimum length".
> ===
> 
>> 3.2 <https://tools.ietf.org/html/draft-ietf-regext-org-06#section-3.2>.  
>> Organization Roles
>> The organization roles are used to represent the relationship an
>>organization would have.  Its corresponding element is .
> 
> ⇒ MUST instead of would
> 
> An organization object MUST always have at least one associated role. Roles 
> can be set only by the client that
> Sponsors an organization object. A client can change the role of an 
> organization object using the EPP  command.
>  [Linlin] Yes.
> ===
> 
>> 3.2.1 <https://tools.ietf.org/html/draft-ietf-regext-org-06#section-3.2.1>.  
>> Role Type
>> An organization would support a list of roles.  See Section 7.3 
>> <https://tools.ietf.org/html/draft-ietf-regext-org-06#section-7.3> for a
>>list of values.  Its corresponding element is .
> 
> I think the sentence is wrong. You should talk about role type, not about 
> "list of roles"
> 
> An organization role MUST have a type. […]
> 
> [Linlin] "An organization role MUST have a type which support a list of 
> values.  See Section 7.3 for the role type values."
> ===
> 
>> 3.2.2 <https://tools.ietf.org/html/draft-ietf-regext-org-06#section-3.2.2>.  
>> Role Status
>> A role of an organization object would have its own statuses.  Its
>>corresponding element is .  The values of the role status
>>are defined in Section 3.5 
>> <https://tools.ietf.org/html/draft-ietf-regext-org-06#section-3.5>.
> 
> I'm not sure if "would" is the best word to use here.
> 
> An organization role MAY have a status. […]
> 
> [Linlin] OK.
> ===
> 
>> 3.4 <https://tools.ietf.org/html/draft-ietf-regext-org-06#section-3.4>.  
>> Organization Status Values
> 
> 
> I think you forgot to specify that
> 
> "linked" status MUST NOT be combined with either "clientLinkProhibited" or 
> "serverLinkProhibited" status.
> 
> Or is this in case you want to block linking while there are still links? If 
> so, it's useful to specify this:
> 
> A client or server MAY combine linked with either clientLinkProhibited or 
> serverLinkProhibited if new links must be prohibited [...]
> 
> [Linlin] Yes, "clientLinkProhibited" or "serverLinkProhibited" can combine 
> with "linked" if new links must be prohibited. Your suggested sentence will 
> be added.
> ===
> 
>> 3.5 <https://tools.ietf.org/html/draft-ietf-regext-org-06#section-3.5>.  
>> Role Status Values
>> 
>> […]
>> 
>> o  ok: This is the normal status value fo

Re: [regext] Interest in collaborating on an EPP over HTTP draft?

[Pieter Vandepitte]

Hi Anthony,

Exactly the same question as Patrick. As I'm not in the registrar world, but 
the registry world, I'm very interested in the use cases (or why) of EPP over 
HTTP instead of EPP over TCP. But very willing to collaborate if there's a case 
(not just because it is technically more fun to do)

Kind regards

Pieter

> On 23 May 2018, at 03:29, Patrick Mevzek  wrote:
> 
> Hi Anthony,
> 
> On Tue, May 22, 2018, at 18:09, Anthony Eden wrote:
>> I've thrown together a repo over at GitHub to work on an EPP over HTTP
>> draft (https://github.com/aeden/epp-over-http). I'd love to know if there
>> are others from the community who are interested on collaborating.
> 
> As I am sure you are aware, some registries currently uses HTTPS, like .IT
> and .PL at least.
> It may be a good idea, if not already, to try sharing discussions with them 
> and see if you can converge on something, if you are planning to do a 
> standard.
> 
> You may also be aware that when EPP itself was drafted they were then 
> multiple other proposals for transport, besides TLS. There was at least SMTP 
> if I recall correctly and BXXP (BEEP) which I think does not really exist 
> anymore but it looks like to me that many of its features are also present 
> nowadays in HTTP/2.
> 
> Maybe there are some ideas to grab from these past attempts, the documents 
> themselves or the discussions.
> 
>> As a
>> registrar, we'd love to be able to work with registries using HTTP as the
>> transport protocol in the future.
> 
> I am curious, why particularly prefering HTTP over TCP (or more precisely 
> HTTPS over TLS)?
> 
> Did you tak time already to document the differences with TCP, in the realm 
> of EPP, what are the benefits and the drawbacks?
> 
>> Note that the current version of this draft deals solely with EPP over HTTP
>> 1.1, it does not consider HTTP 2 at this time.
> 
> (I did not look at your code/document yet).
> Why is it so?
> Just a lack of time or some specific reason against HTTP/2?
> 
> If there anything that works with HTTP/1.1 but not /2 it should be documented.
> As nowadays, for new works, I think it is best to concentrate on the newer
> versions of other standards when you do a layering (hence HTTP/2) instead 
> of forcing retro-compatibilies, except if good reasons for that of course, 
> this is what I am curious about. 
> 
> -- 
>  Patrick Mevzek
> 
> ___
> 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] WGLC: draft-ietf-regext-org-02

[Pieter Vandepitte]

Hi Patrick,

I respect your opinion and my gut feeling says it won't be used for anything 
else than resellers. But I might be wrong (and history tells me the odds are 
agains me :-)). I also respect the opinion of others and it's not up to me to 
assess in depth the needs of other registries, I can only challenge and trust 
other participants to act truthful. More important to me, the model seems 
correct and logical, with the others' point of view and needs in the back of my 
head. 
The only thing that bothers me in general (not only for this extension) is the 
low participation in discussion making it difficult to develop a specification 
that fits all needs. 

I do not agree with you regarding not moving forward. A lot of registries 
-including the one I work for- are reluctant to implement anything other than 
RFCs (how many extensions with status Informational in the EPP extensions 
registry are implemented by more than 1 registry?)
Registrars are not happy with ad hoc extensions and I share their concerns. 
Moving forward is the necessary step to be able to converge to a single 
implementation for modelling resellers (and to enable interoperability)

It is certainly not my intention to try to convince you to approve the draft. I 
will continue my write-up but I will write down your concerns and it's up to 
others to decide whether the Draft can become a Proposed Standard

Kind regards

Pieter


> On 24 May 2018, at 07:44, Patrick Mevzek <p...@dotandco.com> wrote:
> 
> On Wed, May 23, 2018, at 13:36, Pieter Vandepitte wrote:
>> @Patrick, did you have time in mean time to catch up? How would you like 
>> the draft to be changed in order to support it? 
> 
> I unfortunately think that I am not convinced by the use case, and I believe 
> that the document could be an I-D referenced on the IANA EPP Extensions 
> registry without the need to become an RFC. Which other registry wish to use 
> it on their systems? And if there is, then for other things than resellers?
> 
> That does not change anything on the WG consensus on the documents, which 
> should proceed on their own pace.
> 
>> I guess it's the fact 
>> that roles are defined as properties of the organization and at the same 
>> time as properties of the link?
> 
> Yes, that is one troublesome point I raised months ago.
> 
> -- 
>  Patrick Mevzek
> 
> ___
> 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] Object template extension

[Pieter Vandepitte]

Hi all,
 
The registry I work for, developed a custom extension to manage "nameserver" 
groups and "keygroups". When a registrar links a group to a domain, all member 
nameservers/keys of that group are automatically linked to that domain. This 
way, it is very convenient for DNS operators to update DNS data on their 
complete domain portfolio with a single group update, without forgetting a 
domain.
 
It is used quite a lot, but I did not find other registries having this kind of 
functionality (I did not perform an extensive search). I'm quite sure we are 
not the only ones, so do you know other registries having this?
 
Is there any interest from the community to offer such a feature to their 
registrars and collaborate on a common extension? I think of something more 
generic in a way that a registrar can create a "template" for any kind of 
object and apply that template to other objects. This way, besides the benefits 
for DNS operators, a registrar could also define e.g. a default admin contact 
for every domain, or even apply custom extensions to every domain…
 
Any feedback welcome
 
Kind regards,
 
Pieter___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] WGLC: draft-ietf-regext-org-02

[Pieter Vandepitte]

Hi all,

Other thoughts? I think it's important as document shepherd to know whether we 
should move on or not.

Kind regards

Pieter

> On 21 May 2018, at 05:19, Patrick Mevzek  wrote:
> 
> On Fri, May 11, 2018, at 15:32, James Galvin wrote:
>> With that, version 06 of this document has been published and the chairs 
>> are declaring WGLC closed.  The document is now ready for submission to 
>> IESG for consideration as a Proposed Standard.
> 
> Isn't that a little rushed?
> 
>> From a quick search I have found about only 2 explicit mention of support of 
>> this document, from Pieter and Scott (as for myself I can not say I 
>> explicitely support it because I am still uneasy by the need for it or not 
>> seeing it and still not understanding some part of it like all the "role" 
>> part).
> 
> Also the document went into so many iterations during the period that it was 
> basicaly impossible to follow
> (one night I have tried reviewing its newest version by implementing it in my 
> client... to find out in the morning that a new version went out so I kind of 
> decided to stop giving it my time before it stabilizes in some way); some new 
> comments even just popped out on the mailing-list yesterday.
> 
> So I feel uneasy process-wise. Based on the amount of iterations during WGLC 
> it looks like to me that there is at least still some work needed on it, and 
> I am not sure its current version correspond really to the working group 
> consensus.
> 
> The above applies the same way for the two "organization" documents.
> 
> -- 
>  Patrick Mevzek
> 
> ___
> 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] REGEXT Interim Meeting

[Pieter Vandepitte]

Maybe I’m missing something, but this draft is about validating contacts, so I 
don't see an issue in referring to the contact RFC. There’s no point in 
validating contacts, but not creating them, so the client needs to support the 
contact xsd anyway.

Regardless of that, I’m still trying to figure out the use of this extension. 
Will a client first check whether a contact can be created, then interpret the 
response of the check, and finally create the command. Or will the client just 
try to create the contact, and in case of error interpret the error message? 
Maybe there’s a need for better, more structured and machine interpretable 
responses, but I don’t think the extra check step is the way to go. Just my 2 
cents…

Kind regards

-- 
Pieter Vandepitte
Product Expert
+32 16 28 49 70
www.dnsbelgium.be 

 
 
On 06/06/18 14:22, "regext on behalf of Gould, James"  wrote:

Patrick,

The base EPP protocol is defined using epp and eppcom, where extensions 
(object or command / response) would naturally be dependent on the base 
schemas.  Creating dependencies across extensions does not allow them to stand 
on their own, so my preference would be to copy and paste the elements from 
sibling extension XML schemas unless there is a large advantage with creating 
the dependency.  There are examples of cross extension dependencies that exist 
today, like the inclusion of the host XML schema within the domain XML schema 
of RFC 5731.  This dependency does require ensuring that the host XML schema is 
loaded ahead of the domain XML schema when pre-caching the XML schemas.  The 
contact reference in the validate extension takes it one step further by 
referencing complex types that requires the use of the contact namespace 
directly within the XML, so it's more than just ensuring that the contact XML 
schema is loaded ahead of the validate XML schema.  It is not hard to overcome, 
but I believe the priority should be to have the extensions stand on their own 
and only be dependent on the base XML schemas of epp and eppcom unless there is 
an overriding reason to add the cross-extension dependency.  

  
—
 
JG



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

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

Verisign.com <http://verisigninc.com/> 

On 6/5/18, 8:09 PM, "regext on behalf of Patrick Mevzek" 
 wrote:

On Mon, Jun 4, 2018, at 19:56, Gould, James wrote:
>   4.  I don’t recommend directly referencing the 
> urn:ietf:params:xml:ns:contact-1.0 elements, since it adds a direct 
> dependency to inclusion of the contact XML schema and namespace for a 
> subset of the elements that are really specific to the validate 
mapping.  
> I would prefer for the validate XML schema to stand on its own by 
only 
> referring to epp and eppcom, with no cross references to contact.  
This 
> would mean copying and pasting elements directly from the contact XML 
> schema into the validate XML schema, which is an inconvenient, but 
makes 
> it easier to implement.

I am sure that not all elements of epp/eppcom namespaces are used 
either so under symmetry and consistency I would find more logical that all 
schemas are treated the same, either all referenced, or all copied (for the 
parts needed).

And I see no problems in referencing the contact-1.0 one.
Using epp/eppcom as references already make the schema dependent on 
other resources and not "standing on its own".

I am not sure this has a huge consequence on implementations, 
especially if taking into account multiple ways to implement things (and 
especially doing validation or not).

-- 
  Patrick Mevzek

___
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 mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] I-D Action: draft-ietf-regext-org-ext-07.txt

[Pieter Vandepitte]

Hi Linlin,

Thanks for updating the draft. Small issue: in 4.3 you did not specify the 
status of an org object after returning the action pending responses. I would 
add something similar like RFC 5731:

   The status of the organization object after returning this response MUST
   include "pendingCreate".  The server operator reviews the request
   offline, and informs the client of the outcome of the review either
   by queuing a service message for retrieval via the  command or
   by using an out-of-band mechanism to inform the client of the
   request.


Kind regards

-- 
Pieter Vandepitte
Product Expert
+32 16 28 49 70
www.dnsbelgium.be <http://www.dnsbelgium.be>
 

 
 

On 15/06/18 02:48, "regext on behalf of internet-dra...@ietf.org" 
 wrote:


A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Registration Protocols Extensions WG of 
the IETF.

Title   : Organization Extension for the Extensible 
Provisioning Protocol (EPP)
Authors : Linlin Zhou
  Ning Kong
  Junkai Wei
  Xiaodong Lee
  James Gould
Filename: draft-ietf-regext-org-ext-07.txt
Pages   : 24
Date: 2018-06-14

Abstract:
   This document describes an extension to EPP object mappings, which is
   designed to support assigning an organization to any existing object
   (domain, host, contact) as well as any future objects.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-regext-org-ext/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-regext-org-ext-07
https://datatracker.ietf.org/doc/html/draft-ietf-regext-org-ext-07

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-regext-org-ext-07


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
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] REGEXT Interim Meeting (Validate Draft)

[Pieter Vandepitte]

Thanks, Roger,

It now makes much more sense to me.

Kind regards

Pieter

--
Pieter Vandepitte
Product Expert
+32 16 28 49 70
www.dnsbelgium.be<http://www.dnsbelgium.be>

[DNS_PUNT_Belgium_RGB]


From: regext  on behalf of Roger D Carney 

Date: Monday 11 June 2018 at 17:44
To: "regext@ietf.org" 
Subject: Re: [regext] REGEXT Interim Meeting (Validate Draft)

Good Morning,

I will be sending out minutes/notes of the Interim meeting later this week.

I agree with what Jim proposed during the meeting and here in reference to 
providing ids for new/existing contacts, as well as the one to one matching of 
the check/response items.

Just for a little color/background on the issues/goals of this draft. From a 
registrar standpoint we have run into difficult customer registration 
processing flows when we go to do a domain create and assign “roles” to 
contacts. Registrars can create “valid” contacts at a registry only to find out 
later (during domain create) that the “valid” contact created earlier is not 
valid for a specific contact type/role. Many registries have different policies 
around different contact types/roles (e.g. either the Registrant or Admin must 
have a postal address from a certain country but both are not required to), but 
you can only confirm this on a domain create when the contact type/role is 
being assigned. This is a huge headache for customers. They have already 
selected a domain name, provided contacts, provided payment and now find out 
they may not be eligible for the domain (and now wait for a refund) or have to 
edit contacts again because the registrar was not able to validate the contact 
information for the contact type/role earlier in the process. I hope this helps 
explain the issue/goal for this draft more clearly.


Thanks
Roger


From: regext [mailto:regext-boun...@ietf.org] On Behalf Of Gould, James
Sent: Monday, June 11, 2018 9:27 AM
To: Pieter Vandepitte ; Gould, James 
; Patrick Mevzek ; 
regext@ietf.org
Subject: Re: [regext] REGEXT Interim Meeting


Pieter,



Regardless of that, I’m still trying to figure out the use of this extension. 
Will a client first check whether a contact can be created, then interpret the 
response of the check, and finally create the command. Or will the client just 
try to create the contact, and in case of error interpret the error message? 
Maybe there’s a need for better, more structured and machine interpretable 
responses, but I don’t think the extra check step is the way to go. Just my 2 
cents…



Based on my deep dive into draft-ietf-regext-validate, my take of the draft is 
that it’s used to validate the use of an existing or new contact as a contact 
type for a domain name of a tld.   A little of the confusion discussed during 
the REGEXT Interim Meeting was how the client specifies the use of an existing 
or new contact.  One assumption that I made was the reference to an existing 
contact was made by only including a contact id () and definition 
of a new contact to validate was made by the inclusion of the additional 
contact attributes (, etc.).  That was not the case, since 
the extension supported reuse of new contact attributes for a different contact 
type and tld by referencing a contact id included earlier in the check command. 
 Take a look at the use of the “sh8013” contact id in the check command 
example, where it’s fully defined for the “registrant” type and the “COM” tld, 
but only referenced by contact ID for the subsequent “tech” type and “COM” tld. 
 Also notice that the contacts are consolidated in the check response by 
contact ID.  In the validate check command there are 4 contacts and the 
validate check response has only two.  My recommendation was to support 
referencing an existing contact by only supplying the contact ID, don’t create 
dependencies between check items to reduce the amount of duplicate information 
provided, and ensure that the number of items in the check response match the 
number of items in the check command.





—



JG







James Gould

Distinguished Engineer

jgo...@verisign.com<mailto:jgo...@verisign.com>



703-948-3271

12061 Bluemont Way

Reston, VA 20190



Verisign.com <http://verisigninc.com/>



On 6/11/18, 4:53 AM, "Pieter Vandepitte" 
mailto:pieter.vandepi...@dnsbelgium.be>> wrote:



Maybe I’m missing something, but this draft is about validating contacts, 
so I don't see an issue in referring to the contact RFC. There’s no point in 
validating contacts, but not creating them, so the client needs to support the 
contact xsd anyway.



Regardless of that, I’m still trying to figure out the use of this 
extension. Will a client first check whether a contact can be created, then 
interpret the response of the check, and finally create the command. Or will 
the client just try to create the contact, and in case of error interpret the 
error message? Maybe there’s a need for better, more structured and machine

Re: [regext] FW: New Version Notification for draft-gould-regext-login-security-00.txt

[Pieter Vandepitte]

I have nothing to add. Just letting know I share the same opinion.

-- 
Pieter Vandepitte
Product Expert
+32 16 28 49 70
www.dnsbelgium.be <http://www.dnsbelgium.be>
 

 
 

On 14/06/18 00:45, "regext on behalf of Patrick Mevzek" 
 wrote:



On Mon, Jun 11, 2018, at 19:43, Gould, James wrote:
> In thinking about decreasing the minimum from 8 to 1, I have a concern 
> that we're going to support a minimum that is below the existing RFC 
> 5730 of 6 characters.  I believe it would be best for the Login Security 
> Extension to at least support the existing 6 character minimum with the 
> added language that Scott proposed “Servers SHOULD enforce minimum and 
> maximum password length requirements that are appropriate for their 
> operating environment. One example of a guideline for password length 
> policies can be found in  [reference here]".  Scott's 
> language can be added to the Security Considerations section of the 
> draft.
> 
> Let me know if this will work.  

I do not oppose that if this is the consensus but I still see it as 
pointless to provide *any* specific minimum limit here, and I do not see the 
problem with going lower than RFC5730 since this extension is optional and, 
hopefully, if it is used it means the relevant registry has decided to put more 
energy and work around security measures so you could hope they would deal with 
this minimum issue gracefully (that is enforcing something higher than 6, and 
not lower, if they do define the space of characters allowed too).

-- 
  Patrick Mevzek

___
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] Delegated EPP

[Pieter Vandepitte]

Hi,

As I see discussions popping up now and then of 3rd party organisations having 
to modify registry objects, wouldn't it be an idea to design something like 
delegated EPP instead of implementing new protocols? Something like: a 
registrar assigns a group to an object, then generates a token for the group 
and shares it with a 3rd party. Could be more or less complex, introducing 
users, etc.

I'm probably reopening old discussions, but maybe worth thinking of.

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

Re: [regext] Object template extension

[Pieter Vandepitte]

Thanks Patrick for the full history on templates and groups

In mean time I looked to the .cz extension and it seems they serve the same 
purpose.

I think the 2 flavours for nameservers should not be an obstacle. When using a 
template, it would be possible to use either host links vs host attributes. It 
depends on how you design it.

I see a big difference with bulk updates. Bulk updates equals to lots of data 
to be transferred.
With templates, you further "normalize" the data model. It is comparable with 
contact updates: when you change the name of a contact, all WHOIS data of 
domains having the same contact id are updated with a single update command. 
When you change a template by updating nameservers/DNSSEC data/..., all DNS 
data of domains having the same template id are updated with a single command. 
The client is relieved of the burden to check whether all domains with the same 
DNS "profile" are updated and it does not have to perform a bulk update of 
thousands of domains.

I'm also not in favour of a protocol extension for bulk updates. The reason is 
that it is already possible. A client may handle updates asynchronously and can 
shoot a list of command to the EPP server. 

Kind regards

Pieter


> On 26 May 2018, at 04:48, Patrick Mevzek  wrote:
> 
> Pieter,
> 
> On Fri, May 25, 2018, at 21:37, Pieter Vandepitte wrote:
>> The registry I work for, developed a custom extension to manage 
>> "nameserver" groups and "keygroups". When a registrar links a group to a 
>> domain, all member nameservers/keys of that group are automatically 
>> linked to that domain. This way, it is very convenient for DNS operators 
>> to update DNS data on their complete domain portfolio with a single 
>> group update, without forgetting a domain.
>> 
>> It is used quite a lot, but I did not find other registries having this 
>> kind of functionality (I did not perform an extensive search). I'm quite 
>> sure we are not the only ones, so do you know other registries having 
>> this?
> 
> I know two extensions:
> 
> - the .BE/.EU one: the last time I have looked at them, it was the same, 
> except for the namespace
> - the .CZ one, in fact in their Fred open source EPP server (so probably used 
> for their others TLDs), see 
> https://fred.nic.cz/documentation/html/EPPReference/ManagedObjects/Nssets.html
> and
> https://fred.nic.cz/documentation/html/EPPReference/ManagedObjects/Keysets.html
> 
> 
>> From memory, they cater for the same needs, but are basically incompatible, 
>> besides the namespace.
> Starting with the terminology: "group" on one side, "set" on the other.
> 
> I would add 2 remarks:
> - for nameservers it seems to me to make more sense when hosts are objects, 
> instead of attributes while obviously it works in both case. The world is 
> quite divided on this, gTLDs are mostly (only?) in the objects group, while 
> ccTLDs are predominantly in the attributes group
> - for DNSSEC material, here we hit another problem, the DS vs DNSKEY 
> dichotomy, partially reflected in the dsData vs keyData interfaces of 
> secDNS-1.1
> All grouping cases only make sense of course with the DNSKEY case, because 
> the DS depends on the domain. Again, without any hard facts, I still believe 
> that most registries are using the DS case. Some, even with the dsData 
> interface, ask also for the underlying keyData, but only to check that the DS 
> was correctly computed.
> 
> Also, such kind of features have consequences for transfers.
> 
>> Is there any interest from the community to offer such a feature to 
>> their registrars and collaborate on a common extension? I think of 
>> something more generic in a way that a registrar can create a "template" 
>> for any kind of object and apply that template to other objects. This 
>> way, besides the benefits for DNS operators, a registrar could also 
>> define e.g. a default admin contact for every domain, or even apply 
>> custom extensions to every domain…
> 
> Note that there were various attempts to define features such as templates, 
> containers, or bulk operations.
> 
> Specifically for bulk operations, since the discussions often circled around 
> that the primary argument was that EPP is a provisioning protocol and as such 
> is not tailored for bulk operations. Which brings immediately this counter 
> argument: ... but you can query for more than one object in a given  
> command.
> 
> Note that while not completely the same, issues of "bundling"  domain names 
> due to IDN variants typically is also loosely related to all of this.
> 
> One of the latest iteration around these concepts was this draft:
> https:/

Re: [regext] Delegated EPP

[Pieter Vandepitte]

Besides DNSSEC, I'm thinking of NS data and reseller data

kind regards

Pieter


> On 30 May 2018, at 11:10, Kal Feher  wrote:
> 
> Hi Pieter,
> 
> could you elaborate on what objects you think might be modified? Are you 
> thinking of anything other than DNSSEC material?
> 
> delegation of epp to 3rd parties that are unknown to the registry does have 
> some operational implications that need to be thought through. Although I 
> suppose this group isnt regops.
> 
> 
> On 29/5/18 6:13 am, Pieter Vandepitte wrote:
>> Hi,
>> 
>> As I see discussions popping up now and then of 3rd party organisations 
>> having to modify registry objects, wouldn't it be an idea to design 
>> something like delegated EPP instead of implementing new protocols? 
>> Something like: a registrar assigns a group to an object, then generates a 
>> token for the group and shares it with a 3rd party. Could be more or less 
>> complex, introducing users, etc.
>> 
>> I'm probably reopening old discussions, but maybe worth thinking of.
>> 
>> Pieter
>> ___
>> regext mailing list
>> regext@ietf.org
>> https://www.ietf.org/mailman/listinfo/regext
> 
> -- 
> Kal Feher
> Melbourne, Australia
> 
> ___
> 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] FW: New Version Notification for draft-gould-regext-login-security-00.txt

[Pieter Vandepitte]

I follow the concerns of Patrick,

I'm neither a fan of the [LOGIN-SECURITY]. Isn't it enough to specify that a 
server MUST ignore the value of  if the loginSec extension is used?

I don't know if I overlooked it, but it seems that there's only support for 
password based login and provisioning. Do you plan to support other things like 
digest authentication?

Kind regards

Pieter


On 05/06/18 07:32, "regext on behalf of Patrick Mevzek" 
 wrote:

On Mon, Jun 4, 2018, at 22:30, Gould, James wrote:
> The Login Security Extension (draft-gould-regext-login-security) was 
> posted 
> (https://datatracker.ietf.org/doc/draft-gould-regext-login-security/) 

Thanks James, this is nice.

Some comments before really trying to implement it:

- I am not a huge fan of the [LOGIN-SECURITY] token, but I see no good 
alternatives. Specifically, this variant forbids any later revision of the 
specification. So I would either argue for the shortname, loginSec-1.0, so that 
at least it will be backwards compatible or, to be bolder, use RFC when 
 will be known...
Or to want to avoid collisions at all cost, I would either go towards 
something like U+001A (SUBSTITUTE) or U+001B (ESCAPE) repeated 16 times.

Or a completely different route would be to use the XML ID/IDREF mechanism.
I am not 100% sure but maybe the current  could have an xml:IDREF 
attribute with a path pointing to the new loginSec:pw node which would have the 
corresponding xml:ID attribute?

- for loginSec:pw/loginSec:newPw I am not a fan of specifying minimum 
length, because if you remove all maximum length constraint in the schema for 
the maximum, by symmetry I would do the same for the minimum, leaving both to 
pure policy choices by the server (the "sensible"  minimum depends of course on 
the number of different characters allowed, it would not be the same value when 
accepting only ASCII or when accepting "any" Unicode characters

- I would also not put anything here related to what characters are allowed 
or not. I would instead defer to the PRECIS framework (RFC7564) and more 
specifically section 4 of RFC8265. At least as a base, using OpaqueString and 
then building one more constrained on top of it if it is really deemed important
(passwords here are typically not seen nor managed by humans, so I think 
they need less strict rules than when handled by humans, and I see no problems 
per se with spaces... I have seen far more trouble when people try to use < or 
& in a password and forgetting to encode it as those are specific characters in 
an XML streams).

I know that RFC5730 does the same thing, but it was written before PRECIS.
So now I think we should instead build on it.

-- 
  Patrick Mevzek

___
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] I-D Action: draft-ietf-regext-change-poll-06.txt

[Pieter Vandepitte]

Just a small note... Shouldn't section 3.1.2 be renamed to EPP  Command? 
I think the purpose of the extension is to extend poll messages, no?

Moreover, the draft talks about


Example poll  response

I think that's an error. Poll info does not exist. It should be poll req


Pieter

On 05 Jan 2018, at 14:08, 
internet-dra...@ietf.org wrote:


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Registration Protocols Extensions WG of the 
IETF.

   Title   : Change Poll Extension for the Extensible Provisioning 
Protocol (EPP)
   Authors : James Gould
 Kal Feher
Filename: draft-ietf-regext-change-poll-06.txt
Pages   : 25
Date: 2018-01-05

Abstract:
  This document describes an Extensible Provisioning Protocol (EPP)
  extension for notifying clients of operations on client sponsored
  objects that were not initiated by the client through EPP.  These
  operations MAY include contractual or policy requirements including
  but not limited to regular batch processes, customer support actions,
  Uniform Domain-Name Dispute-Resolution Policy (UDRP) or Uniform Rapid
  Suspension (URS) actions, court directed actions, and bulk updates
  based on customer requests.  Since the client is not directly
  involved or knowledgable of these operations, the extension is used
  along with an EPP object mapping to provide the resulting state of
  the post-operation object, and optionally a pre-operation object,
  with the operation meta-data of what, when, who, and why.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-regext-change-poll/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-regext-change-poll-06
https://datatracker.ietf.org/doc/html/draft-ietf-regext-change-poll-06

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-regext-change-poll-06


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
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] I-D Action: draft-ietf-regext-change-poll-06.txt

[Pieter Vandepitte]

After some iterations of reading your reply and the draft I think I start to 
get it :-)

The extension is to be used only in a response of an EPP info command.

The whole poll thing confused me, because, how I interpret RFC 5730, an EPP 
poll response is the response to the epp:poll command (with the "op" attribute 
either "req" or "ack"), but here, poll response has a different meaning. It 
means any response having a msgQ element. To me, a response having a msgQ 
element is not a poll response, but just a response (check response, info 
response, poll response, create response, delete response, ...) containing a 
"hint" there are poll messages available.

This makes me thinking: wouldn't it be useful to allow the use of the extension 
in case of a transform response (like domain update) or a poll response (like 
poll ack, which I initially had in mind when reading the draft for the first 
time)? I think it is :-)

Best regards

Pieter


On 08 Jan 2018, at 14:28, Gould, James 
<jgo...@verisign.com<mailto:jgo...@verisign.com>> wrote:

Pieter,

Thank you for your review and feedback.

The extension is a command / response EPP extension of any object (e.g., 
domain, host, contact) that the server needs to inform the client of changes 
via a poll message that is an extension of the object’s info response.  A poll 
response is a standard EPP response with the msgQ element populated.  The key 
choice for a poll message is which concrete EPP response to use.  In the case 
of draft-ietf-regext-change-poll, the extension of an object-specific info 
response is used.  The change poll message could have leveraged an object 
extension (e.g,. change record), but that would have required finding some 
mechanism to replicate the state attributes of an extensible set of objects 
(e.g., domain, host, contact).  The title of section 3.1.2 as EPP  
Command is in line with other command / response EPP extensions.  I believe the 
example reference to “poll  response” is accurate, since a poll command 
does result in a poll response which in this case is an extended 
object-specific info response.  Does referring to it as “poll message  
response” make it a little bit clearer in the examples?

Thanks,

—

JG



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

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

Verisign.com<http://verisigninc.com/>

From: regext <regext-boun...@ietf.org<mailto:regext-boun...@ietf.org>> on 
behalf of Pieter Vandepitte 
<pieter.vandepi...@dnsbelgium.be<mailto:pieter.vandepi...@dnsbelgium.be>>
Date: Monday, January 8, 2018 at 3:11 AM
To: "regext@ietf.org<mailto:regext@ietf.org>" 
<regext@ietf.org<mailto:regext@ietf.org>>
Subject: [EXTERNAL] Re: [regext] I-D Action: 
draft-ietf-regext-change-poll-06.txt

Just a small note... Shouldn't section 3.1.2 be renamed to EPP  Command? 
I think the purpose of the extension is to extend poll messages, no?

Moreover, the draft talks about


Example poll  response


I think that's an error. Poll info does not exist. It should be poll req


Pieter

On 05 Jan 2018, at 14:08, 
internet-dra...@ietf.org<mailto:internet-dra...@ietf.org> wrote:


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Registration Protocols Extensions WG of the 
IETF.

   Title   : Change Poll Extension for the Extensible Provisioning 
Protocol (EPP)
   Authors : James Gould
 Kal Feher
Filename: draft-ietf-regext-change-poll-06.txt
Pages   : 25
Date: 2018-01-05

Abstract:
  This document describes an Extensible Provisioning Protocol (EPP)
  extension for notifying clients of operations on client sponsored
  objects that were not initiated by the client through EPP.  These
  operations MAY include contractual or policy requirements including
  but not limited to regular batch processes, customer support actions,
  Uniform Domain-Name Dispute-Resolution Policy (UDRP) or Uniform Rapid
  Suspension (URS) actions, court directed actions, and bulk updates
  based on customer requests.  Since the client is not directly
  involved or knowledgable of these operations, the extension is used
  along with an EPP object mapping to provide the resulting state of
  the post-operation object, and optionally a pre-operation object,
  with the operation meta-data of what, when, who, and why.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-regext-change-poll/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-regext-change-poll-06
https://datatracker.ietf.org/doc/html/draft-ietf-regext-change-poll-06

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-regext-change-poll-06


Please note that it may take a cou

Re: [regext] AD Review: draft-ietf-regext-org-ext-07

[Pieter Vandepitte]

Hi Linlin,

Other RFC’s do not specify the error codes in particular cases (e.g. 5731 does 
not specify what to return if you remove a linked contact does not exist). But… 
on the other hand, I think it can be very useful if all Registries use the same 
error codes for the same use cases.
It’s just that if you start to specify them, you have to be as complete as 
possible. You can’t randomly pick some cases. There are quite a lot of other 
cases, so where do we stop? E.g. deleting an organization object which is 
already linked, add a link for which the organization does not exist, … to just 
name a few of them.

Isn’t this useful content for some kind of Best Practices document?

Kind regards

Pieter

--
Pieter Vandepitte
Product Expert
+32 16 28 49 70
www.dnsbelgium.be<http://www.dnsbelgium.be>

[DNS_PUNT_Belgium_RGB]



From: regext  on behalf of Linlin Zhou 

Date: Thursday 9 August 2018 at 05:12
To: Adam Roach , draft-ietf-regext-org-ext 
, regext 
Subject: Re: [regext] AD Review: draft-ietf-regext-org-ext-07

Dear Adam and WG,
Sorry, please ignore last unfinished letter.

We've received some comments on the appropriate error codes. Since 
draft-ietf-regext-org-ext is a command / response extension of another object 
that is related to a link attribute, 2305 seems like a more proper error code 
for all of them, which means "Object association prohibits operation". The 
association dould refer to an existing association (e.g., attempt to add alink 
that already exists) or a requested association (e.g. attempt to remove a link 
that does not exist).
We found that in RFC5730 , the document already defined the response format 
with error value elements using  or  for an object. So we 
suggest not defining the specific response format in this command/response 
extension.
The co-authors have discussed this issue and suggested the following changes.

An EPP error response MUST be returned if an  command cannot be 
processed for any reason.
An attempt to add one organization ID or multiple organization IDs with a 
particular role value when at least one of them already exists does not change 
the object at all. A server SHOULD notify clients that object relationsips exit 
by sending a 2305 error response code.
An attempt to remove an organization ID or multiple organization IDs with a 
particular role value when at least one of them does not exist does not change 
the object at all. A server SHOULD notify clients that object relationships 
does not exist by sending a 2305 error response code.
An attempt to change an organiztion ID or multiple organization IDs with a 
particular role value when at least one of them does not exist does not change 
the object at all. A server SHOULD notify clients that object relationships 
does not eixt by sending a 2305 error response code.
Response format with error value elements is defined in section 2.6 of RFC5730.

Regards,
Linlin

zhoulin...@cnnic.cn

From: Linlin Zhou<mailto:zhoulin...@cnnic.cn>
Date: 2018-08-08 13:06
To: Adam Roach<mailto:a...@nostrum.com>; 
draft-ietf-regext-org-ext<mailto:draft-ietf-regext-org-...@tools.ietf.org>; 
regext<mailto:regext@ietf.org>
Subject: Re: Re: [regext] AD Review: draft-ietf-regext-org-ext-07
Dear Adam,
I have included my feedbacks for the remaining issues. Please see below.

Regards,
Linlin

zhoulin...@cnnic.cn

From: Adam Roach<mailto:a...@nostrum.com>
Date: 2018-08-07 07:51
To: Linlin Zhou<mailto:zhoulin...@cnnic.cn>; 
draft-ietf-regext-org-ext<mailto:draft-ietf-regext-org-...@tools.ietf.org>; 
regext<mailto:regext@ietf.org>
Subject: Re: [regext] AD Review: draft-ietf-regext-org-ext-07
Responses inline.

On 7/30/18 1:21 AM, Linlin Zhou wrote:
Dear Adam,
Thanks for your review. I have my feedbacks started with [Linlin]. I'll update 
the draft based on your comments.

Regards,
Linlin

zhoulin...@cnnic.cn<mailto:zhoulin...@cnnic.cn>

From: Adam Roach<mailto:a...@nostrum.com>
Date: 2018-07-28 07:04
To: draft-ietf-regext-org-ext<mailto:draft-ietf-regext-org-...@tools.ietf.org>; 
regext@ietf.org<mailto:regext@ietf.org>
Subject: [regext] AD Review: draft-ietf-regext-org-ext-07
This is my AD review for draft-ietf-regext-org-ext-07.  I have a handful of
comments below that I'd like to see addressed prior to asking the IESG to
consider the document. Please treat them as you would any other last-call
comments.

There are also two blocking comments that need to be resolved prior to
IETF last
call.

Thanks to everyone who worked on this document.

---

This is a blocking comment.

This document raises the same question as draft-ietf-regext-org-08 does
regarding the allowable placement of XML namespace declarations within the
document; see, e.g., the following text:

>  In addition to t

Re: [regext] New Version Notification for draft-gould-carney-regext-registry-00.txt

[Pieter Vandepitte]

Did anyone consider RFC 6321 (xcal)? It has features like recurrences too. A 
maintenance event is basically just a calendar event + some data about the 
scope/context...

Kind regards

-- 
Pieter Vandepitte
Product Expert
+32 16 28 49 70
www.dnsbelgium.be <http://www.dnsbelgium.be>
 

 
 

On 10/08/18 00:08, "regext on behalf of Patrick Mevzek" 
 wrote:

On Mon, Jun 11, 2018, at 15:48, Gould, James wrote:
> More specifically now, about "2.3.  Schedule" I am *strongly* 
> against using the format proposed for at least 2 reasons:
> - crontab format is not a standard, and is ambiguous for various 
> points
> - it encodes a format as a string which is itself in a formatted 
> structure since it is XML. "Hijacking" some free form space when you are 
> in formatted structure seems wrong to me and shows that the structure is 
> not correctly formatted because if it were you would not have to inject 
> a new format in a free text.
> 
> Why not use ISO8601 Repeated Time Interval format? We are then still 
> gulty of the previous point but at least it is a standard.
> Otherwise please amend the XML structure to break the content 
> currently in the crontab format.

Another way of encoding that, without judging myself if it is 
good/bad/better or worse than others but just to open horizons and see what is 
out there since I just stumbled upon it for unrelated reasons, is the systemd 
way, as described on 
https://www.freedesktop.org/software/systemd/man/systemd.time.html

With this example:

Thu,Fri 2012-*-1,5 11:12:13

The above refers to 11:12:13 of the first or fifth day of any month of the 
year 2012, but only if that day is a Thursday or Friday.

HTH,

-- 
  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] REGEXT Interim Meeting (2018JUN05) Notes

[Pieter Vandepitte]

Short question regarding the validate extension:

Isn’t the purpose of the validate extension to do what actually transactions 
are meant for? Ultimately the goal of the validate extension is to check 
whether a group of commands are possible: create some contacts, link the 
contacts to a domain with a specific role.
Why not trying to add a layer on top of EPP to enable transactions? Start a 
transaction, add commands to a transaction, execute a transaction with either 
commit or auto roll back?
I think that would lead to a much simpler model and could easily deal with 
other objects and other extensions.

Thoughts?

Pieter


--
Pieter Vandepitte
Product Expert
+32 16 28 49 70
www.dnsbelgium.be<http://www.dnsbelgium.be>

[DNS_PUNT_Belgium_RGB]



From: regext  on behalf of Roger D Carney 

Date: Tuesday 3 July 2018 at 20:04
To: Registration Protocols Extensions 
Subject: [regext] REGEXT Interim Meeting (2018JUN05) Notes

Sorry about the tardiness, please enjoy, see everyone in a couple weeks.

Meeting started at 11:06 (UTC-5)

Attendees: Roger Carney, James Gould, Jody Kolker, Jim Galvin

Agenda
1.Validate draft (comments, concerns, implementations)
2.Registry Mapping
a.Continue the lively discussion that was started in London
b.Policy Extension Review: how a server implements an extension, the 
SHOULD(s), MAY(s), etc.

Jim Galvin mentioned that co-chairs have been discussing milestones and updated 
charter with AD (Adam). Hopefully circulate new Charter to the group next week. 
Planning two meetings for IETF-102.

James Gould said that he has started implementing the Validate draft in their 
SDK. I mentioned that Nominet has already implemented.

We started out discussing the Validate draft, specifically the questions James 
Gould posted to the list Monday June 4, 2018, copied below:

1.I don’t see the purpose of the  element in the check 
command..  Initially, I thought the  may support a list within a 
list (e.g., ), but that is not the case.  There is also a 
little confusion with the use of  in both the check command and 
response.  My recommendation is to remove the  element from the 
check command and simply move all its sub-elements to sub-elements of the 
 element. [Interim] Interesting for removal, post to list.
2.Is the extension meant to validate the contact details of existing 
contacts by contact id and also non-existent contacts based on the contact 
details, by contact type and by tld?  [Interim] Yes, both scenarios. For “new” 
contacts pass all data, don’t try to short cut it with only id, if only id is 
passed server will assume it is an existing contact. Change response 
validate:cd to include TLD and contact type attributes. Discussed the 
preferences of smaller payload versus complicated payload, went with simpler. 
Add a new section to 2.0 describing validate:id (Need to have response pass 
back contact type and tld).
a.If both cases are true, then wouldn’t you have a choice of referencing 
the contact by identifier for an existing contact or defining the contact 
attributes for a non-existing contact?
b.Also, what if you desire to use the same contact information for multiple 
contact types for a tld?

  1.  Do you need to replicate the same attributes for each contact type?  
[Interim] Simple method would
  2.  It may be better to define a single contact (existing with contact 
identifier) or contact attributes for non-existing with the list of contact 
types.  I imagine that you always want to validate a contact within the scope 
of a tld.  [Interim] Interesting, thoughts?
3.I view definition of only the check command and response with many 
contacts and with extensibility via the kv elements as somewhat non-optimal.  
Other options include:
a.Instead of supporting multiple contacts in an individual command, why not 
support the check or info of an individual contact with attribute extensibility 
via command / response extensions.  Yes, you can validate only a single contact 
with multiple target types and a tld at a time, but you get to use existing 
contact command / response extensions to define the additional contact 
attributes without having to use key / value pairs.  [Interim] One goal is to 
pass in multiple contacts and validate as a whole
b.Create a validate command / response extension of the contact mapping 
that extends the contact create to function as a no-op with the additional 
attributes used to validate usage of the contact (e.g., object - domain, 
contact types, tld), which would define a validate contact validate create 
command.  The contact info could have been extended by the validate extension 
to function as a validate usage command with the usage attributes consistent 
with the contact validate create command (e.g., object – domain, contact types, 
tld).  In this case, the contact commands can be directly extended by the 
validate extension. [Interim] So does key/value make sense here. Can this 
va

Re: [regext] WGLC: draft-ietf-regext-org-02

[Pieter Vandepitte]

I don't want to delay the publication, and I support it, but there are still 
some issues/concerns

Typos/errors

> EPP provides two commands to retrieve domain information

Should be: "EPP provides two commands to retrieve organization information". 

>This document does not define a mapping
>for the EPP  command to retrieve domain-object transfer
>status information..

change domain-object to organization-object

> 
>EPP provides four commands to transform organization object
>information:  to create an instance of an organization
>object,  to delete an instance of an organization object,
> to manage organization-object sponsorship changes, and
> to change information associated with an organization
>object.  This document does not define a mapping for the EPP
> and  command.

It should be three commands. (Also remove the part "  to manage 
organization-object sponsorship changes,"). 
(I'm even not sure that the draft should not support transfer. )

In 4.2.1:

>o  A  element that contains the operational status of the
>   organization, as defined in Section 3.4 
> .


I think it's zero, one or more org:status elements. It can be 
clientUpdateProhibited and clientDeleteProhibited at the same time for 
instance...


Food for thought:

Postal Info

(1) Why do we still stick to the original model of contacts as the new model 
for organization, with postal info is required (and within the postalInfo, name 
and address is required)? I think, we should be very cautious when making 
attributes required. If it's required for the protocol, I agree, but this is 
not the case. It's more a policy thing, which must be described in other 
documents (like ICANN policy documents). E.g. at .be, we are considering to 
model resellers, but we don't need the address, only the URL. Moreover, this 
original contact model can potentially become problematic in the context of 
GDPR (although i don't see a lot of issues with reseller contact data)

(2) I would not define a postalInfo type. The sole purpose as far as I can 
think of, is to make the postal info legible for people that use ascii script 
in their language (transliteration). If transliteration would be the use case, 
I would not restrict that to transliterations between ascii and "the rest", but 
then I would define a "script" or "lang" tag, which defines the script of the 
postal info, and allow zero to infinite postalInfo elements to allow multiple 
transliterations (not only to us-ascii).
( As a side note: I always struggled with the "int" type. For me, "Int" = 
"international" = any script / character set allowed, which is the opposite)

(3) As mentioned in a previous post, I still doubt the need for different 
contact types within an organization, but let's make abstraction of that... 
Can't the organization's postalInfo data be modeled as a linked contact? Much 
simpler


Organization Roles

(1) Although I doubt the need for a roleid, I think we should either remove it, 
or extend it. The role id is the id of the organization in a third party source 
(e.g. in case of a Registrar, IANA is a third party source, and id is "the 
IANA-id"). It is IMO possible that an object is known in different sources with 
different "IDs"
So, for completeness, the org:roleid should have an attribute indicating the 
authoritative source of the id, in case of a Registrar IANA id, it could be 
"iana". 

(2) As I understand, organization roles can be used in links. But what if a 
link exists for a specific role, and the organization role is removed 
afterwards from the organization? As I understand from James in a previous 
reply to Patrick, this should match (in fact it's a MUST). This is not 
described as far as I can see. Wouldn't it be a good idea, in order to have a 
unambiguous understanding, to describe that in draft-ietf-regext-org-ext 
(create, update) and in draft-ietf-regext-org (update, delete)? 



Kind regards

Pieter



> On 13 Apr 2018, at 15:21, James Galvin  wrote:
> 
> The document editors have indicated that the following document is ready for 
> submission to the IESG to be considered for publication as a Proposed 
> Standard:
> 
> Extensible Provisioning Protocol (EPP) Organization Mapping
> https://datatracker.ietf.org/doc/draft-ietf-regext-org/
> 
> Please indicate your support for the publication of this document.
> 
> If any working group member objects to the publication of this document 
> please respond on the list by close of business everywhere, Friday, 27 April 
> 2018.  If there are no objections the document will be submitted to the IESG.
> 
> During the last call the chairs are looking for a document shepherd for this 
> document.  If you are interested in being the document shepherd please let 
> the chairs know.  The document editors cannot be the document shepherd.
> 
> If you’ve never been a document shepherd before 

Re: [regext] WGLC: draft-ietf-regext-rdap-object-tag

[Pieter Vandepitte]

>  
> (1) I think the solution is just not right. It's a quick and dirty way of 
> doing these things. The right way imo is defining a new RDAP extension (with 
> a dedicated attribute to identify the authoritative source)
> (2) In my opinion there are other, existing, mechanisms for discovering 
> entities (and mentioned in the draft: self links). 
>  
> I think you have the use case incorrect. This isn’t about discovering 
> entities, it’s about being able to bootstrap a query for an entity when you 
> have no other information available in much the same way that domain queries 
> can be bootstrapped as described in RFC 7484. You can’t use self links if all 
> you have to start with is something that looks like “ABC123”. So please fill 
> me in if you can think of a way for a client to receive an entity handle like 
> “ABC123” and determine which is the authoritative server for that entity in 
> the absence of any other information.
>  


No, indeed it isn't about discovering entities, but discovering the 
authoritative server for an entity, basically wat is meant with bootstrapping. 

There are basically 2 use cases I can think of: (1) you need to discover an 
entity referred to by another object (e.g. domain) and (2) you need to discover 
an entity for which you only have the handle.

For the first one, RFC 7484 gives some hints how this could be achieved and I 
think alternatively you could introduce a new attribute or use the self links. 
Maybe we agree on that one?

For the second use case, as you noticed rightly, there's currently no way a 
client can guess where the query should be sent to, if you only have the 
handle. I agree upon that. 
The solution now is: let's extend the handle, and append it with the repo, then 
the client needs to parse it, discover the URL and send the entity lookup 
request to that URL.
My solution would be: let's extend the client and let it accept a second 
argument for the repo. The client still needs to discover the URL (using the 
second argument), but you can skip that parsing thing in the clients and no 
need for an RFC to solve this issue.  (I agree we need a "Bootstrap Service 
Registry for Entities")

So my final vote on this draft: if there's a need for "globally unique handles" 
(I'm not convinced they are needed to help the clients), then yes, go ahead, 
but I would prefer a hyphen (it works, as long as the repos do not have 
hyphens), the same as roid in EPP.

Kind regards,

Pieter

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

Re: [regext] WGLC: draft-ietf-regext-org-02

[Pieter Vandepitte]

Thanks Linlin!

Seems OK for me

> Zero or more OPTIONAL org:status elements


Optional here is not necessary, since it's zero, imo, but maybe sometimes you 
can't be explicit enough i think ;-)

Kind regards

Pieter


> On 16 Apr 2018, at 11:52, Linlin Zhou <zhoulin...@cnnic.cn> wrote:
> 
> Dear Pieter,
> Thanks for your support. I'll update the text according to your comments. 
> Please see some my feedbacks inline.
> 
> Regards,
> Linlin
> zhoulin...@cnnic.cn <mailto:zhoulin...@cnnic.cn>
>  
> From: Pieter Vandepitte <mailto:pieter.vandepi...@dnsbelgium.be>
> Date: 2018-04-13 22:06
> To: James Galvin <mailto:gal...@elistx.com>
> CC: Registration Protocols Extensions <mailto:regext@ietf.org>
> Subject: Re: [regext] WGLC: draft-ietf-regext-org-02
> I don't want to delay the publication, and I support it, but there are still 
> some issues/concerns
> 
> Typos/errors
> 
>> EPP provides two commands to retrieve domain information
> 
> Should be: "EPP provides two commands to retrieve organization information". 
> 
>>This document does not define a mapping
>>for the EPP  command to retrieve domain-object transfer
>>status information..
> 
> change domain-object to organization-object
> [Linlin] These typos will be modified.
>> 
>>EPP provides four commands to transform organization object
>>information:  to create an instance of an organization
>>object,  to delete an instance of an organization object,
>> to manage organization-object sponsorship changes, and
>> to change information associated with an organization
>>object.  This document does not define a mapping for the EPP
>> and  command.
> 
> It should be three commands. (Also remove the part "  to manage 
> organization-object sponsorship changes,"). 
> (I'm even not sure that the draft should not support transfer. )
> 
> [Linlin] Yes. Words will be updated.
> 
> In 4.2.1:
> 
>>o  A  element that contains the operational status of the
>>   organization, as defined in Section 3.4 
>> <https://tools.ietf.org/html/draft-ietf-regext-org-02#section-3.4>.
> 
> 
> I think it's zero, one or more org:status elements. It can be 
> clientUpdateProhibited and clientDeleteProhibited at the same time for 
> instance...
> [Linlin]  I'd like to change the text to "Zero or more OPTIONAL org:status 
> elements".
> 
> Food for thought:
> 
> Postal Info
> 
> (1) Why do we still stick to the original model of contacts as the new model 
> for organization, with postal info is required (and within the postalInfo, 
> name and address is required)? I think, we should be very cautious when 
> making attributes required. If it's required for the protocol, I agree, but 
> this is not the case. It's more a policy thing, which must be described in 
> other documents (like ICANN policy documents). E.g. at .be, we are 
> considering to model resellers, but we don't need the address, only the URL. 
> Moreover, this original contact model can potentially become problematic in 
> the context of GDPR (although i don't see a lot of issues with reseller 
> contact data)
> 
> (2) I would not define a postalInfo type. The sole purpose as far as I can 
> think of, is to make the postal info legible for people that use ascii script 
> in their language (transliteration). If transliteration would be the use 
> case, I would not restrict that to transliterations between ascii and "the 
> rest", but then I would define a "script" or "lang" tag, which defines the 
> script of the postal info, and allow zero to infinite postalInfo elements to 
> allow multiple transliterations (not only to us-ascii).
> ( As a side note: I always struggled with the "int" type. For me, "Int" = 
> "international" = any script / character set allowed, which is the opposite)
> 
> (3) As mentioned in a previous post, I still doubt the need for different 
> contact types within an organization, but let's make abstraction of that... 
> Can't the organization's postalInfo data be modeled as a linked contact? Much 
> simpler
> [Linlin] As I expalined before, our requirements was to have a reseller 
> extension with its own contacts and hierarchy. So we keep the postInfo part 
> of RFC5733 to store the address information. For most of the registries and 
> registrars, this structure is more familiar with them. 
> 
> Organization Roles
> 
> (1) Although I doubt the need for a roleid, I think we should either remove 
> it, or extend it. The role id is the id of the organization in a third party 
> source (e.g. in case 

Re: [regext] WGLC: draft-ietf-regext-rdap-object-tag

[Pieter Vandepitte]

Hi, my 2 cents:

(1) I think the solution is just not right. It's a quick and dirty way of doing 
these things. The right way imo is defining a new RDAP extension (with a 
dedicated attribute to identify the authoritative source)
(2) In my opinion there are other, existing, mechanisms for discovering 
entities (and mentioned in the draft: self links).

So, for me, it's a no, I don't support it as it is now.

Kind regards

Pieter

> On 13 Apr 2018, at 12:54, Hollenbeck, Scott  wrote:
> 
>> -Original Message-
>> From: regext [mailto:regext-boun...@ietf.org] On Behalf Of James Galvin
>> Sent: Friday, April 06, 2018 9:59 AM
>> To: Registration Protocols Extensions 
>> Subject: [EXTERNAL] [regext] WGLC: draft-ietf-regext-rdap-object-tag
>> 
>> The document editors have indicated that the following document is ready
>> for submission to the IESG to be considered for publication as a Best
>> Current Practice:
>> 
>> Registration Data Access Protocol (RDAP) Object Tagging
>> https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-object-tag/
>> 
>> Please indicate your support for the publication of this document.
>> 
>> If any working group member objects to the publication of this document
>> please respond on the list by close of business everywhere, Friday, 20
>> April 2018.  If there are no objections the document will be submitted to
>> the IESG.
> 
> It's been one week with no feedback at all. Come on, folks, please speak up! 
> One of our obligations as working group members is to review and discuss the 
> documents being developed in the group. It helps the document shepherd, the 
> WG chairs, and the IESG to get a better measure of consensus based on the 
> discussion. It's OK to say, "I've read the document and I have no concerns"! 
> The IETF doesn't charter "lurking" groups, people!
> 
>> During the last call the chairs are looking for a document shepherd for
>> this document.  If you are interested in being the document shepherd
>> please let the chairs know.  The document editors cannot be the document
>> shepherd.
> 
> I've found someone who is willing to be the document shepherd. I'll give him 
> a "please identify yourself" poke shortly.
> 
> Scott
> ___
> regext mailing list
> regext@ietf.org 
> https://www.ietf.org/mailman/listinfo/regext 
> 


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] REGEXT Interim Meeting (2019JUN11) Notes

[Pieter Vandepitte]

Thanks for the minutes. This also triggered me to re-read the DSF draft :)

Regarding reporting,

I don’t know the details of the conversations in that meeting, but keep in mind 
that we are not the first ones to invent the wheel...

There are initiatives like CSV on the web 
(https://www.w3.org/TR/tabular-data-primer/), DCAT 
(https://www.w3.org/TR/vocab-dcat/ ) or https://schema.org to describe data 
sets and/or catalogs

Regarding the draft,

Without questioning the usefulness of this draft, I don’t see the use case for 
EPP (intro), so I would try to come up with other examples.
The current EPP specifications do not prevent a client to perform “bulk 
updates”, it’s just the clients that are not smart enough. If clients would 
operate asynchronously (not waiting for a server response), the only overhead 
is the verbosity of XML (vs. message RTT when operating synchronously). I doubt 
that this is a real issue (except if you’re provisioning billions of 
objects/updates)...

Also, it would be nice if the draft would build upon existing initiatives (like 
the ones above) to describe the data set metadata...

Just my 2 cents...

Pieter

From: regext  on behalf of Roger D Carney 

Date: Wednesday, 3 July 2019 at 14:17
To: "regext@ietf.org" 
Subject: [regext] REGEXT Interim Meeting (2019JUN11) Notes

Meeting minutes from our quick Interim Meeting on June 11th, enjoy! See 
everyone in a few weeks.

Meeting started at 11:04 (UTC-5)

Attendees: Roger Carney (GoDaddy), Gordon Dick (Nominet), Joseph Yee (Afilias)


Agenda

  1.  Reporting 
Repository/Structure/Reports
 (how does the Data Set File 
Format fit in).

We talked for about 15 minutes, I suggested that we would schedule a meeting 
before the next IETF, maybe the first couple weeks of July.

We agreed that expanding the specific communications protocol from just sFTP to 
a small number of them (sFTP or HTTPS or ??) would be good for the registry 
side. As for using the Data Set File format suggested by Gould, we thought that 
it seemed to be overly complex/heavy handed for this scenario, though we would 
like to have a fuller discussion around how/where it does fit.

Jim Gould was not able to make it, but he did send me these notes: “I just 
wanted to let you know that the Data Set File format draft has not been updated 
yet to support reports, but I have a domain model defined that would support 
defined bulk operations with the definition and data in a single file and 
report definition with the definition in a separate file with a reference to 
the report data file.  The report defining and data can be contained in a 
single file, but I anticipate that it will be a separate file.  The meta data 
about the report including its format is in the definition along with the 
definition of a type that can be registered in an IANA registry.  A registry 
could implement  a registered report and even extend it by adding more fields.  
Clients that are not interested in the additional fields can process the field 
based on the IANA registered definition.  Both standard reports and custom 
reports can be defined using a common set of meta data and a common set of 
field elements.  The field elements are defined using XML schema types and can 
be fully validated by a processor.  Custom field elements can be defined.  The 
field definition approach is taken from the CSV data escrow format and the 
existing Data Set Format draft.  The key with the approach is that we can 
define the Wild West using a standards based mechanism that will support 
automation and provide a lighter weight mechanism for standardization with the 
use of an IANA registry that contains the report definition with a unique type 
identifier.  There can also be sub-types to support additional granularity.  I 
intend to make a dent in updating the draft this month.”



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