Re: [urn] Reminder: Namespace Identifier: Formal Request for EIC

[[e-mail]]

From: Elena Nikitina <[e-mail]>
To: "[e-mail]" <[e-mail]>
Date: Fri, 5 Nov 2021 10:22:58 +0000
Archived-At: <https://mailarchive.ietf.org/arch/msg/urn/bipBobW-qYSdGtYp4mvSwIIdQ3I>

Elena Nikitina <[e-mail]> writes:
> Additionally I would like to underline that the requested registration
> for EIC in my previous e-mail is still required. Therefore I would
> kindly ask you to proceed with the next steps if no other actions are
> required from my side.

I have searched at the mail archive for "[e-mail]"
(https://mailarchive.ietf.org/arch/) and for unknown reasons, your
e-mail message of 3 Sept 2021 not recorded there.  It appears that there
has been some problem regarding its delivery.

> From: Elena Nikitina
> Sent: 03 September 2021 10:41
> To: [e-mail]
> Cc: Olivier Aine <[e-mail]>; Dr. Chavdar Ivanov <[e-mail]>; [e-mail]
> Subject: Namespace Identifier: Formal Request for EIC

> Please find attached the completed registration request for EIC.

> [application/pdf EIC urn registration Request_ENTSOE_20210903.pdf (177kB)]

I have read the registration request.  It is straightforward, other than
that several items refer to ENTSOE documents available on the ENTSOE web
site.  This is inconvenient from the IETF's point of view but I see no
reason to object to the registration because of that.

The syntax notation in the registration is clumsy (compared to other
IETF documents), but it is entirely clear in practice.

The registration does not describe an equivalence rule (see RFC 8141
section 6.4.2 item 3) but since the EIC identifiers consist entirely of
the characters 0-9, A-Z (upper case only), and -, it is clear that exact
equality of the NSS is intended.

The only issue I identify is in the description of the algorithm for
computing the check character (the 16th character of the EIC = NSS),
which is given in
https://eepublicdownloads.entsoe.eu/clean-documents/EDI/Library/cim_based/EIC_Data_Exchange_IG_v1.1.pdf
"ENTSO-E EIC DATA EXCHANGE IMPLEMENTATION GUIDE" clause 5.3.2 lines
266-267, which say "Then, the positions are again weighted, beginning
with the greatest value to the left and ending with a one at the far
right." but the illustration immediately following shows "2" at the far
right, and the later text makes clear that "2" is intended for the
process of calculating the check character.  ("1 at the far right" would
be correct for the process of *verifying* the check character.)

However, this is clearly an erratum, as anyone attempting to implement
the calculation according to this document would immediately discover
the intended meaning.

I believe this document should be approved.

Dale