Re: [regext] I-D Action: draft-ietf-regext-simple-registration-reporting-06.txt

["Gould, James" <[e-mail]>]

Joseph,

Thank you for responding to my feedback and posting the updates in draft-ietf-regext-simple-registration-reporting-07.   I provide feedback to your comments embedded below and prefixed with “JG – “.

I have the following high-level suggestions:


  1.  Split the draft into two separate drafts, with the first being a standards track draft that covers the framework elements (format, IANA registries, and a base set of report elements), and the second being an informational track draft that includes reports that use the framework.  The framework should be flexible enough to support the definition of many report elements and many reports.
  2.  To support an extensible set of report element values, such as transactions and objects, the Data Element Definition registry can be expanded to support typed elements, with the initial set including (fields, transactions, and objects).  This is like the RDAP JSON Values registry that supports multiple types of values.  This way new types of transactions and objects can be registered that are unique and are described.  The Data Element Definition attributes currently include: Name of data element, Reference document, Registrant, and Status.  It’s unclear what the purpose of the Status attribute is.  My recommended set of attributes include Name, Type, Description, Registrant, and Reference.  This would be an exact match to the RDAP JSON Values registry except for the use of the Name attribute instead of the Value attribute.  Additional element types could also be defined, similar to the definition of two new types “redacted name” and “redacted reason” for draft-ietf-regext-rdap-redacted in the RDAP JSON Values registry.  Having a Report Element Definition registry that includes many types of elements as well as the ability to define new types will provide for the needed extensibility.

--

JG

[cid:image001.png@01D8809F.C2C33CC0]

James Gould
Fellow Engineer
[e-mail]<applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[e-mail]>

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

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

From: Joseph Yee <[e-mail]>
Date: Wednesday, June 8, 2022 at 5:23 PM
To: James Gould <[e-mail]>
Cc: "[e-mail]" <[e-mail]>
Subject: [EXTERNAL] Re: [regext] I-D Action: draft-ietf-regext-simple-registration-reporting-06.txt

Hi Jim and all,

Please see my comment inline. The -07 should come out shortly or out already.

On Fri, Mar 25, 2022 at 10:44 AM Gould, James <jgould=[e-mail]<mailto:[e-mail]>> wrote:

Hi,



I did a detailed review of draft-ietf-regext-simple-registration-reporting-06 and below is my feedback:


1.   Introduction
a.    I’m not sure whether there have been “a number of best practice reports that have evolved”, but I do agree that there have been “a number of best practices that have evolved”.
updated

1.
a.
b.   Nit – “data element aforementioned data element registry” to “data element registry”.
updated

1.
a.
2.   Data Element Specification
a.    Nit – “printed report” could simply be “report”.  I don’t believe printed is relevant.
updated

1.
a.
b.   There is no definition of the format used for the data element names (e.g., upper case, lower case, camel case, snake case).  The names are inconsistent, but they primarily support the use of upper-case leading words, with the use of underbars as a word separator.  My recommendation is to formally define the expected data element names and ensure that all the data element names follow the defined format.
Added text about naming convention.


JG – Good, it may be best to revise the description in draft-ietf-regext-simple-registration-reporting-07 to be “The data elements MUST use the naming convention of words starting with an upper-case character, followed by lower-case characters, and using an underbar as a word separator.  The Augmented Backus-Naur Form (ABNF) grammar [RFC5234<https://datatracker.ietf.org/doc/html/rfc5234>] format is:



ELEMENT = WORD *( “_” WORD )

WORD    = UPPER *LOWER

UPPER   = %x41-5A ; A-Z

LOWER   = %x61-7A ; a-z

1.
a.
b.   Overall
                                                                                          i.   We need to ensure that only elements that are standard elements (non-proprietary) are pre-defined.
                                                                                        ii.   We need to ensure to use a consistent naming convention.
                                                                                      iii.   We need to look to support a candidate list of registration elements that are in line with the elements defined and the naming conventions used in the relevant EPP RFCs.
Agree as a general guideline, and *may* make exceptions on a case by case basis.

JG – I’m unclear where exceptions would be made and why.

1.
a.
                                                                                          i.
2.   General Data Elements
a.    Transaction_Type
                                                                                          i.   How do you deal with extensions to the commands outlined in RFC 5730, such as the restore request, restore response, or operations that are not defined in RFC 5730, such as auto renew?
[seeking more input] I intend to add the following paragraph under 'Transaction Type'.  Would love to hear more feedback before adding it.
"Well known and important transactions like restore where it was documented inside EPP extension, and auto renew invoked by the registry system that alter the domain's status are allowed."

JG – The draft should support an extensible set of transactions, which means that the Transaction_Type can have a pre-defined list, but new transaction types can be added.  My recommendation is to revise the Data Element Definition registry to support typed elements, with a “transaction” type, and an initial set of transaction type values (“create”, “delete”, “renew”, “transfer”, and “update”, “restore”, “autorenew”).

a.
                                                                                          i.
b.   Object_Type
                                                                                          i.   Since EPP extension can define a new object, then the Object_Type also needs to be extensible, such as the definition of an Email Forwarding, Defensive Registration, or NameWatch objects for .NAME.
This seems to be getting into proprietary objects, or additional information to the domain object, imo.

JG – The draft should support an extensible set of transactions, which means that the Object_Type can have a pre-defined list, but new transaction types can be added.  My recommendation is to revise the Data Element Definition registry to support typed elements, with a “object” type, and an initial set of transaction type values (“domain”, “host”, “contact”).

1.
a.
                                                                                          i.
b.   DateTime
                                                                                          i.   Shouldn’t this be Date_Time to be consistent with the format of the other data elements?
updated

1.
a.
                                                                                          i.
b.   Term
                                                                                          i.   Why not use Period instead of Term to be consistent with the element used in EPP?
Changed to 'Period', and the old Period (meant for unit) changed to 'Period_Unit'

JG – Yes, that makes sense.

1.
a.
                                                                                          i.
b.   Fee
                                                                                          i.   I would reference the use of “decimal” for the format, since referencing “balanceType” is unrelated to representing a fee.  The “balanceType” is a decimal value to support a positive (fee) or negative (credit) value, so referencing “decimal” is best.
I believe that balanceType is based on decimals.  I have not reviewed this one fully.  Will revise after further review.

JG – My recommendation is to remove the dependency to RFC 8748 by referencing “decimal” instead of “balanceType”.

1.
a.
                                                                                          i.
b.   Status
                                                                                          i.   A status is an individual value.  How do you handle a report that has more than one status?  Does that mean adding multiple rows to the report, each with a different status value?  How do you handle representing additional statuses, such as the RGP statuses?
                                                                                        ii.   My recommendation is to add a Statuses element that supports a list of statuses that is an encoded element in double quotes, such as “clientUpdateProhibited,clientRenewProhibited”.
Added text about multiple values, separated by comma, and enclosed them in double quote as specified in RFC4180 (about csv)

JG – Are you going to stick with the singular name (“Status”) or change the name to plural (“Statuses”)?  One nit in draft-ietf-regext-simple-registration-reporting-07, is to change “separated by symbol comma” to “separated by a comma”.  Also, it may be better to replace “under double quotes” to “in double quotes”.

1.
a.
                                                                                          i.
b.   Registrar
                                                                                          i.   There is the chance that the free-form registrar name could include the delimiter, so the use of quoting will be needed.
Added text about possible of having a comma in the string, and enclosed them in double quote as specified in RFC4180 (about csv) if needed

JG – One nit in draft-ietf-regext-simple-registration-reporting-07, is to change “The string must be under double quotes if it contains comma symbol as specified in RFC 4180 [RFC4180]’ to “The string must be in double quotes if it contains a comma, as specified in RFC 4180 [RFC4180]”.
1.
a.
                                                                                          i.
b.   Period
                                                                                          i.   Why not call this Unit to be consistent with the EPP term?  The term is reflected using the pUnitType in RFC 5731.
Changed to 'Period_Unit' instead of just 'Unit'

JG – Yes, that works.

1.
a.
                                                                                          i.
2.   Domain Price Data Elements
a.    Same feedback on the use of the unrelated “balanceType” in RFC 8748.  The recommendation is to simply refer to the type “decimal” to support positive and negative values.  The alternative for fees is to only support positive values with the “nonNegativeDecimal” type in RFC 8748, since I don’t believe the price values should be negative.
Same feedback above.

JG - My recommendation is to remove the dependency to rfc 8748 by referencing “decimal” instead of “balanceType”.

1.
a.
b.   I believe all the Price Data Element should include an indication that it’s a price or a fee, such as prefixing “Price_” for each of them.  So, it would be “Price_Domain_Create”, “Price_Domain_Renew”, “Price_Domain_Transfer”, “Price_Domain_Restore”, and “Price_Domain_Trade”.  All the elements should include the object, since there are additional EPP objects that support billable commands.
Updated.
1.
a.
1.
a.
b.   I assume that other billable commands could be supported by defining new custom elements with the pattern “Price_”<Object>”_”<Command>, such as the “Price_Domain_Sync” element for the proprietary sync command defined in https://www.verisign.com/assets/consolidate-mapping.txt.
1.
a.    Trade
                                                                                          i.   Where is a trade defined?  The concept of a trade seems like a proprietary feature that should be moved outside the draft.
[seeking more input] for both proprietary command, sync and trade
Maybe expanding what's allowed in 'Transaction_Type' makes more sense? Thoughts?

JG - My recommendation is add a “transaction” type to the Data Elements Definition registry that supports the registration of new transaction type values.  The sync and trade transaction types and fields can be independently registered.

1.
a.
                                                                                          i.
2.   Timestamp Data Elements
a.    Start_Date
                                                                                          i.   Why not call this Available_Date to match its meaning?  Where is this element used since it overlaps with the Purge_Date element for domains in RGP?
b.   RGP_Date
                                                                                          i.   RGP_Date is not descriptive enough.  I believe this should be Redemption_End_Date.
                                                                                        ii.   Purge_Date

1.      This could be Pending_Delete_End_Date, which is when the purge occurs, and the domain becomes available.
Names updated.
c.    Where is Transfer_Date?
                                                                                          i.   I believe that all the dates in RFC 5731 should be supported at a minimum.
[seeking input]
I haven't added this one as it's not included in any report. Would love to hear more from others of preference, and whether to add this to the report (likely Domain Inventory report).

JG - It would be good to include the candidate set of elements for use in any report.  My recommendation is to go ahead and add the Transfer_Date for completeness.

c.
                                                                                          i.
2.   Registration Information Data Elements
1.   Registrar_ID
                                                                                          i.   You may want to separate Registrar_ID from IANA_ID or GURID to enable inclusion of both.
[seeking more feedback] Keep one or two? IMHO, it's redundant to keep both. Would love to hear from others.
If we keep both, my preference is to name the non-IANA-ID one to 'Registrar_GUID'.
I'm keeping the name 'Registrar_ID' for now.

JG – I’m unclear, are you proposing having a non-IANA ID element with Registrar_ID and having an IANA ID element with Registrar_GURID?  The Registrar_ID can be the internal identifier and the Registrar_GURID is an optional element to be populated for ICANN accredited registrars.

1.
a.
                                                                                          i.
b.   Server_Registrant_ID
                                                                                          i.   Where is a server registrant ID defined?  RFC 5733 defines the use of client assigned identifiers.  This is a proprietary feature that should be moved outside the draft.
                                                                                        ii.   My recommendation is to define a Registrant_ID element that should be defined by the client, per RFC 5733.
I renamed this to just 'Registrant_ID'. This field is meant for mapping the registrant ID shown in WHOIS/RDAP but has no indication of whether the ID was issued by registry or registrar.  I have another two specific contact ID data elements.

JG – Ok, that makes sense.  The name seemed to indicate something that looks to not be an issue.

1.
a.
                                                                                          i.
b.   Server_Contact_ID
                                                                                          i.   Where is the contact ID defined?  RFC 5733 defines the use of client assigned identifiers.  This is a proprietary feature that should be moved outside the draft.
                                                                                        ii.   My recommendation is to define a Contact_ID element that should be defined by the client, per RFC 5733.
This referenced the ID from svTRID.

JG – If this element is meant to be for the EPP svTRID, then shouldn’t it be named Server_Transaction_ID?

1.
a.
                                                                                          i.
b.   In_Use
                                                                                          i.   How about using Linked, which matches the language used in RFC 5733?
Updated.
1.
a.
                                                                                          i.
b.   Nameserver_Host
                                                                                          i.   How about Host_Name to be in line with the naming in RFC 5732?
c.    Nameserver_IP
                                                                                          i.   How about Host_IP or Host_IPs to be in line with the naming in RFC 5732?
                                                                                        ii.   How is the list of IPs handled in the report?
Updated.  Added text about multiple IP addresses separated by comma and wrapped in double quotes.

JG – Ok, that makes sense.

1.
a.
                                                                                          i.
b.   Client_Contact_ID
                                                                                          i.   I recommend changing this to Contact_ID, which is assigned by the client (registrar), per RFC 5733.
This references the ID from clTRID.

JG – If this is meant to match with the EPP clTRID, then my recommendation is to rename the element to Client_Transaction_ID.

1.
a.
                                                                                          i.
2.   Report Definition Specification
a.    “The remaining rows of the file are the unordered sets of data elements, one set per row, where each row is one transaction in the report.”
                                                                                          i.   The data elements are ordered based on the order defined in the header row.  Each row is a record and not a transaction in the report.
Although likely it's ordered by one of the column, we can't guarantee that.  I updated it to 'each row is one record in the report'.

JG – Yes, referring to record instead of transaction hits on my main concern.
1.
a.
                                                                                          i.
b.   I would not refer to them as “transaction rows”, but instead “record rows”.
Updated

1.
a.
b.   High-level, each report definition needs to include a description of the report that defines its purpose.  I assume the frequency of the report would be up to server policy.  As noted in a prior message on the list, I believe the draft needs to focus only on the framework and not the concrete reports.  The first step is to have the capability to formally define the existing reports in a consistent manner and have the reports follow some predefined requirements.
c.    Domain Transaction
                                                                                          i.   I would only include the Registrar_ID in place of including the verbose Registrar for all the transactions, since there could be a very large set of transactions and the Registrar Name can be derived from the Registrar_ID when needed.
It helps the human reader.  Would love to get more feedback from others whether to keep it or not.

JG – The question is who the consumer for the report is.  Is there a report produced per registrar only including their transactions, where the Registrar_ID is somewhat redundant, or is there a single report that produced for all registrars?  My recommendation is to consider the size of the report, and to use Registrar_ID instead of Registrar Name.

1.
a.
                                                                                          i.
                                                                                        ii.   Would it be good to include the domain ROID to uniquely identify the domain name instance?
Would love to hear from others.  It's not that useful IMHO.  Would include it if others find it useful in the report.

JG - If a domain gets added, removed, and re-added, it would be good to know which instance it is.

1.
a.
                                                                                          i.
                                                                                        ii.   The Transaction_Type values will need to support a broader set of types.  We need to take a closer look on how to handle extensibility of Transaction_Type values, since transactions that the registrar does not recognize can be ignored, but at least they have the information available.
Discussed earlier about transaction_type above about 'restore' and 'autorenew'

JG – See my early feedback with making “transaction” a Data Element Definition type with inclusion of the registration of ‘restore’ and ‘autorenew’ transactions.

1.
a.
                                                                                          i.
                                                                                        ii.   The Period, Term, Fee, and Currency will only apply to certain Transaction_Types.
Yes, some rows will have empty value. Do you want this draft to address it, or just let RO to determine if and when they applied to what transactions?

JG – I guess the question is whether all the pre-defined element types can be nullable and to leave the policy up to the RO.

1.
a.
                                                                                          i.
                                                                                        ii.   I’m not exactly sure what the purpose is for the Description for an automated report that can have many transaction records.  I recommend removing the Description unless there is a driving use case for it.
If nobody found them useful, I will remove them in the next iteration.

1.
a.
                                                                                          i.
                                                                                        ii.   Additional element to consider:

1.      Session_ID, Updated_By (could match to Registrar_ID where the Updated_By is more fine-grained to an individual user), ROID (Instance of a domain name), Parent_Transaction_ID if there is a composite transaction.
This seems related to the EPP transactions/logs where I thought the report to be about the record.

JG – These additional elements are not specific to EPP, but would be applicable to any change.

e.    Premium Name
                                                                                          i.   What is the purpose of the Status element?
 Some names could be registered already.

JG – I would provide clarification in the description of the report and the Status element.
e.
                                                                                          i.
                                                                                        ii.   What is the purpose of the Description element?  My recommendation is to remove this element unless there is a concrete reason for it.
Could be additional information from the registry operator about the premium name.

JG – This would naturally be free-form and of less use to automated processing.  I can’t think of the use case for this element, but if you do, please clarify.
e.
                                                                                          i.
                                                                                        ii.   Can the Start_Date be described?
This changed to Available_Date now. Of when the premium name is available for registration.

e.
                                                                                          i.
f.     Domain RGP
                                                                                          i.   I assume that is all domain names in RGP.  Are domain names that are pendingRestore included in this report or only domain names in the RGP redemptionPeriod or pendingDelete?  A description of the purpose of the report and what domain names are included would help.
                                                                                        ii.   As noted previously, the RGP_Date should be named to something like Redemption_End_Date and Purge_Date should be named to something like Pending_Delete_End_Date.
Names updated.
e.
                                                                                          i.
f.     Reserved Domain
                                                                                          i.   How does a reserved domain name have a Status since it should be reserved?  Is the Status meant to indicate whether the reserved domain exists or not, which could happen if an existing domain name is added to the reserved list?
Similar to Premium Name.  It can be registered but still placed under the reserve list.

JG – Ok, adding this to the description would help.

e.
                                                                                          i.
f.     Domain Inventory
                                                                                          i.   Is this the entire inventory of domain names replicated to all registrars or is it a registrar-specific report for domains under management? Based on the elements shown, it looks more like a report used to assist with name spinning than a report to support reconciliation of domain data in the registrar database with the registry database.  The name spinning use case would include the same inventory report to all registrars, and the reconciliation use case would need to include more attributes to fully support syncing the data.
The latter one, specific to the registrar.
What other attributes do you think we need to include?

JG – If the report is meant to be for reconciliation, then there would certainly be more elements that are based on the Domain EPP RFC 5731.

e.    Contact Inventory
                                                                                          i.   There is a need for a description of the purpose of the report, since it’s unclear whether this is generated per registrar and if so, which contacts are included.  Is it all the contacts that is sponsored by the registrar of the report or is it all contacts linked to domain names sponsored by the registrar of the report?
                                                                                        ii.   It’s not clear whether this report is generated per registrar and if it is why would the Registrar_ID element be needed.
It is for each registrar.  I removed 'Registrar_ID' from this report.

JG – If the report is meant for reconciliation, then the elements would need to be based on the Contact EPP RFC 5733.

e.
                                                                                          i.
                                                                                        ii.   I don’t get the purpose of the Server_Contact_ID, since that doesn’t match RFC 5733.
svTRID

JG – I mirror my recommendation to rename this to Server_Transaction_ID.

e.
                                                                                          i.
                                                                                        ii.   I don’t get Domain since a contact can be linked to many domain names.  My recommendation is to remove the Domain element for the many-to-many relationship between domains and contacts.
The current design of this report has the many-to-many relationship. So that it listed not only the contact object, but how it's being utilized with the domain.
Would love to get more feedback from others on what the preference is.

JG – If the report is meant for reconciliation, I recommend sticking to the attributes of the contact based on the Contact EPP RFC 5733.  Providing the link table information between the contacts and domains seems like an argument for a new report, or you can include the contacts in the Domain report.

e.
                                                                                          i.
                                                                                        ii.   What is the purpose of the Contact_Type unless this is meant to represent the linkage of the domains to the contacts?
admin/billing/tech, and yes, linkage to the domain

JG – The contact object doesn’t have a type since it can be used for many contact links from domain names or any other object.  My recommendation is to remove the Contact_Type element, since a contact object doesn’t have a type defined in RFC 5733.

e.
                                                                                          i.
                                                                                        ii.   Is the Registrar_ID associated with the Domain or the Contact.  I would assume the Contact, but I’m not sure.
the latter one, associated with the contact object

e.
                                                                                          i.
f.     Host Inventory
                                                                                          i.   I recommend changing the Nameserer_Host to Host_Name, and the Nameserver_IP to Host_IPs.  The IPs can be a list, so the element should be defined to support a list, with the assumption that they are included in double quotes as in “192.0.2.2,192.0.2.29,1080:0:0:0:8:800:200C:417A”.
Text added for it.

Best,
Joseph

e.
                                                                                          i.





--



JG







James Gould

Fellow Engineer

[e-mail] <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[e-mail]>



703-948-3271

12061 Bluemont Way

Reston, VA 20190



Verisign.com <http://verisigninc.com/<http://secure-web.cisco.com/1c89ftdjrivnzKACKKJ72jY29GQ7DNL1Xx2XFK95cp87ZHz852eFCl_NQvPXKuBf07FBmIdqV-hLmn3_gsuR470zYF1W2KuRGnuY6BdG_zcTSwlK8T3V56-fSMXUAxM2O6eOzG3R7dnG_Gf_Qm4m55tvHhOjfDfce90sW6dLuvhfjcYwPNcvDSFJSLOzopPhxxRkH-7J4kFe_scs43p0E-t5g12K_KvgJS8h1lS6rDqIuqoNFqg2zaa4Et-0egnK8/http%3A%2F%2Fverisigninc.com%2F>>



On 3/7/22, 6:14 PM, "regext on behalf of [e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]> on behalf of [e-mail]<mailto:[e-mail]>> 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           : Simple Registration Reporting

            Authors         : Joseph Yee

                              James Galvin

                Filename        : draft-ietf-regext-simple-registration-reporting-06.txt

                Pages           : 34

                Date            : 2022-03-07



    Abstract:

       Domain name registries (the producer) and registrars (the consumer)

       report to each other by sharing bulk information through files.  This

       document creates two IANA registries to establish a standard

       reporting mechanism between domain name registries and registrars.

       The first IANA registry lists standard data elements and their syntax

       for inclusion in the files.  The second IANA registry lists standard

       reports based on the standard data elements.  Each report is a file

       formatted as a CSV file.  The advantage of this reporting mechanism

       is that a report, each file, can be imported by recipients without

       any prior knowledge of their contents, although reporting is enhanced

       with a minimum of knowledge about the files.  The mechanism for the

       distribution of and access of the files is a matter of local policy.





    The IETF datatracker status page for this draft is:

    https://secure-web.cisco.com/1tuLsav6fXdwNwkI2hRgrcTAmGb46y63uhOddhrLcnDRGZ04vkpVWG6XoEjQ8_x2s_P_iQdnjHFea6CHfHkUea9osOV_kHBtQMFGIxT45AwpWJh9IA-C4bv530agFP_80lDJgaDI3nUgVmG3hvcyjKL6BfO3xU7UdsNlCTPpck9A7fEvmanTd-eu4x0g-N0r03uLNUmz0F-PgkmjOmwJokxKJYjvUEOokgBsMlZfUnF45hnDd16y5xfYS3qoPA_JL/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-regext-simple-registration-reporting%2F



    There is also an HTML version available at:

    https://secure-web.cisco.com/1cxkfGzIwwaxtrPBc-dKkzTbrcM43rhKbUcgKnf4ju60UpDfHrfFurvadAKy0HYgtE8JPliw0q9wk-4yhfizxiU0C9ax9YTm50fwsT_HLO7i6Ziivb8mMUatBWzHgKF1KmXqVhYBeqkq8qWurYZJiexEGtpN8U5rG3agQe9aMpX3tdJcv6v8OAHLFqMSnwQhFiUz9gqtdugbT5HzzZZT6PSNHPgUuTkpB7ip3gjdPHXcizW_RFsz70xqT-k5jkQ4r/https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-ietf-regext-simple-registration-reporting-06.html



    A diff from the previous version is available at:

    https://secure-web.cisco.com/1teV5_jYUfeW36P3uKs-wspFDm4tcZ3UcJREdHCcRKa1FyVsVaWoYz8HQ7TpgpTwJEWNlZHTuqMjOuY4PBr8qrbjZgiwD3-W0TydVlriSfv0cfMT0sE9tAAbmyTuZW5GL6R5NSxkF1xkAFOaTaBc08zroZa5Hb7fW8Zr1A_LsAfWvP8gU5LrKQp_MXoPiSZnq06QFiklpvqkq-EJNSExS4aYBCuMWha3oqkK64W48o98SVZpmMKuIXorVAWTbCZIm/https%3A%2F%2Fwww.ietf.org%2Frfcdiff%3Furl2%3Ddraft-ietf-regext-simple-registration-reporting-06





    Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts





    _______________________________________________

    regext mailing list

    [e-mail]<mailto:[e-mail]>

    https://secure-web.cisco.com/1TWl_oSRF_6eFhgvki-ekeEEj_SaNZQscbHffcoWm5-7LPs33AxYAh6Dw1XyY-mzQLxkWiJF5mjSqCa6f0rTnKSmyYg_ytTWYAWt9Vwlfk0bfDfb0cCqdkm_bLYOWePsWzHqIB3SJEppnIYca5RbTb0Dweh83zA8VNM4wkq_aF5TsgAYjKpRf8VAPCCADGpsQ5eCHsgTIefjUQJIEXgUNIf11pBPngYHc-8DQ4tYshc7RyzLoVu7QiG0FzsKuni69/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext


_______________________________________________
regext mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/regext<https://secure-web.cisco.com/1epkxFus025kqj2_zYhrFBcGOTrGJ9o2NdHdAZSWbYpBdOSZ1s34p1xxBwZQp8-zsQUkD-wR46nEbdOTMSQ6-kQLYKNcHA_Wdu17IV3GtOu6Ff5oY7ZzhvCpaAZHPHaN6o_e_lj_7J4rAHyphv7FlwnoET0by27cHcLOkwzlbwj5YlJgCta2gNHR14vXC7ONCPopvIGW4sMsTGpszBKxVrBIxCy5GU3l3_MmwDbOL-tFTF4sRpsKb0tN4wL5NOuwJ/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext>