Re: [regext] Opsdir last call review of draft-ietf-regext-epp-fees-16

[Carlos Pignataro (cpignata)]

Hi, Barry,

> On Jul 3, 2019, at 9:17 AM, Barry Leiba  wrote:
> 
> Thanks, Carlos, for the review.

Anytime! 

> 
> On one item in your list:
> 
>> 4. S3.4. Does this text imply there is no zero fee or credit possible? Might 
>> be
>> useful to explicitly set guidance for the use of 0/null fee/credit.
>> 
>>   A  element MUST
>>   have a non-negative value.  A  element MUST have a
>>   negative value.
> 
> The text says the fee can be zero ("non-negative"), but the credit
> can't (has to be negative).  That makes general sense, doesn't it?  Do
> you really think there needs to be further explanation of that?

Since zero is neither negative nor positive, I thought it was potentially a 
source of misinterpretation.

But you are correct, the text as-is is accurate and perfect.

That is why I marked these as “Minor comments, questions, and nits for your 
consideration”. As this is an Ops-Dir review, Appendix A of RFC 5706 is 
detailed about defaults, boundary conditions, hence asking :-)

BTW, re-reading that section, I noticed:

   A server MAY respond with multiple  and 
   elements in the same response.  In such cases, the net fee or credit
   applicable to the transaction is the arithmetic sum of the values of
   each of the  and/or  elements.

Do these need to include the same  or otherwise how would the 
arithmetic sum work?

Thanks,

-- Carlos.

> 
> Barry

___
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

Re: [regext] Opsdir last call review of draft-ietf-regext-epp-fees-16

[Barry Leiba]

Thanks, Carlos, for the review.

On one item in your list:

> 4. S3.4. Does this text imply there is no zero fee or credit possible? Might 
> be
> useful to explicitly set guidance for the use of 0/null fee/credit.
>
>A  element MUST
>have a non-negative value.  A  element MUST have a
>negative value.

The text says the fee can be zero ("non-negative"), but the credit
can't (has to be negative).  That makes general sense, doesn't it?  Do
you really think there needs to be further explanation of that?

Barry

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

[regext] REGEXT Interim Meeting (2019JUN11) Notes

[Roger D Carney]

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

[regext] Opsdir last call review of draft-ietf-regext-epp-fees-16

[Carlos Pignataro via Datatracker]

Reviewer: Carlos Pignataro
Review result: Has Nits

Reviewer: Carlos Pignataro
Review Result: Has Nits

I have reviewed this document as part of the Operational directorate's
ongoing effort to review all IETF documents being processed by the IESG.  These
comments were written with the intent of improving the operational aspects of
the IETF drafts. Comments that are not addressed in last call may be included
in AD reviews during the IESG review.  Document editors and WG chairs should
treat these comments just like any other last call comments.

I hope these comments are useful and clear.

>From an operational point of view, the document describes protocol interactions
for dealing with failure conditions, and sets default behaviors. For example,
the RFC 2119 language explaining the use of  is super useful.

Minor comments, questions, and nits for your consideration follow:

1. Section 2 -- Migrating to Newer Versions of This Extension

   (Note to RFC Editor: remove this section before publication as an
   RFC.)

Since forward compatibility is a key operational consideration, why should this
section be removed? Especially when it contains RFC 2119 language.

2. Please do not treat as a pedantic comment, but I did not see an actual
definition for what "fee" and "credit" mean. Since these words have specific
context, it might not hurt to have a formal definition in Section 1.1

3. Should the citation / reference for "ISO 4217" be "ISO 4217:2015"?

4. S3.4. Does this text imply there is no zero fee or credit possible? Might be
useful to explicitly set guidance for the use of 0/null fee/credit.

   A  element MUST
   have a non-negative value.  A  element MUST have a
   negative value.

5. S3.6, why "equal to" and not only "exceed"?

   A server MAY reject certain
   transactions if the absolute value of the  is equal to
   or exceeds the value of the  element.

6. Section 6.1

  * Should  and  markers be used as per the TLP?
  * Should the (c) year be 2019?
  * And should the BSD License be part of the code?

7. Section 7, Security Considerations.

What are "security services"? Further, this protocol deals with on-the-wire
monetary information. I suspect there might be specific such considerations.

8. Section 9.  Implementation Status

If this section is removed, the reference to [RFC7942] would result hanging
without citations to it. ALthough the RFC Editor would catch, might want to
indicate removal of the Normative Reference as well.

Thanks!

Carlos Pignataro.

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

Re: [regext] Proposal about jCard replacement

[Mario Loffredo]

Hi Gavin,

Il 02/07/2019 14:05, Gavin Brown ha scritto:

Hi Mario,

I like JSContact and the current draft certainly looks good enough to be usable 
in RDAP. I imagine more work will be needed before JSContact will have feature 
parity with vCard/jCard.


Yes, the JSCard structure is not completed. I have already defined, 
together with Robert Stepanek, a mapping between JSCard and JCard and it 
seems to us that almost all the information described by JCard can be 
represented by JSCard.  Some JCard elements have a 1-to-1 mapping to as 
many JSCard fields, while some others corresponds to the same field. For 
example, the JCard uri type elements can be represented as items of the 
"online" array, each with appropriate values for "type" and "label" 
properties.


We are also evaluating to add a generic field to represent all the 
information which is not considered at present but it could be in the 
future.



I would be happy to publish a new version of draft-brown-epp-contacts-in-rdap 
which uses JSContact rather than its own representation of contact data. That 
would glue JSContact and RDAP together.


IMHO it would be better to write a new document with the contribution of 
who is willing to implement JSCard in his own RDAP server (you, me, 
maybe Andy). I think other stuff has still to be discussed. For example, 
what to do to make the transition from JCard to JSCard as smooth as 
possible. Should JSCard become the default and JCard an optional 
capability or viceversa? How could an RDAP server inform a client that 
it is able to return contact information according to the JSCard format?


We can have a short talk about it at the next meeting.


Cheers,

mario


G.


On 2 Jul 2019, at 07:58, Mario Loffredo  wrote:

Hi all,

I would like to invite you to take a look at this 
document:https://tools..ietf.org/html/draft-stepanek-jscontact-03

It aims to define a JSON representation of contact information that fixes the 
issues with jCard deserialization and, at the same time, expands vCard 
semantics.

Just to give an idea of the new contact representation in the RDAP context, I 
have implemented an ad-hoc optional capability in .it public test server 
(e.g.https://rdap.pubtest.nic.it/domain/nic.it?jscard=1).

The draft was presented for the first time at last dispatch session in Prague 
and, since then, some feedbacks have been posted on dispatch mailing list which 
have contributed to improve the initial proposal.

Anyway, since the jCard replacement has been debated within this WG, it seems 
to me quite obvious to bring it to your attention.

Any feedback will be very appreciated.

Thanks in advance,

mario

--
Dr. Mario Loffredo
Servizi Internet e Sviluppo Tecnologico
CNR - Istituto di Informatica e Telematica
via G. Moruzzi 1, I-56124 PISA, Italy
E-Mail:mario.loffr...@iit.cnr.it
Phone: +39.0503153497
Web:http://www.iit.cnr.it/mario.loffredo

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


--
Dr. Mario Loffredo
Servizi Internet e Sviluppo Tecnologico
CNR - Istituto di Informatica e Telematica
via G. Moruzzi 1, I-56124 PISA, Italy
E-Mail:mario.loffr...@iit.cnr.it
Phone: +39.0503153497
Web:http://www.iit.cnr.it/mario.loffredo

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