Subject: [Gen-art] Gen-ART review of draft-cridland-acap-vendor-registry-01.txt

From: "Miguel A. Garcia" <[email-masked]>
Date: Tue, 19 Oct 2010 12:14:03 +0200

I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft. For background on Gen-ART, please see the FAQ at 
http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq

Please resolve these comments along with any other comments you may receive.

Document: draft-cridland-acap-vendor-registry-01.txt
Reviewer: Miguel Garcia <[email-masked]>
Review Date: 2010-10-19
IETF LC End Date:
IESG Telechat date: (if known)

Summary: The document has issues that should be addressed before publication.

Major issues:

- I am surprised to see the reduction of characters to ASCII only. I 
don't know how this fits with the IETF Internationalization strategy for 
most protocols. Additionally, this issue touches me personally, as a 
Spanish citizen, where I would not be able to register strings containing 
certain characters due to the lack of their representation in ASCII.

So, this draft is precluding international names be registered with IANA. 
I think this is a major issue that should be addressed.

Minor issues:

- I think this document should update ACAP (RFC 2244). This should be 
visible in the front page, so that the RFC Editor records an update to 
RFC 2244.

- I think that the [ACAP] reference should be promoted to normative 
(moved from Section 7.2 to 7.1).

Nits/editorial comments:

- Section 3, write a formal reference to UTF-8 int he first sentence.

- Section 3.3, last sentence in second paragraph , make a formal 
reference to ANNOTATE.

BR,

      Miguel

-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain

---

From: Dave Cridland <[email-masked]>
Date: Tue, 19 Oct 2010 12:05:31 +0100

On Tue Oct 19 11:14:03 2010, Miguel A. Garcia wrote:
> - I am surprised to see the reduction of characters to ASCII only.  
> I don't know how this fits with the IETF Internationalization  
> strategy for most protocols. Additionally, this issue touches me  
> personally, as a Spanish citizen, where I would not be able to  
> register strings containing certain characters due to the lack of  
> their representation in ASCII.
> 
> So, this draft is precluding international names be registered with  
> IANA. I think this is a major issue that should be addressed.
> 
> 
The original registry definition allowed UTF-8 registrations, but had  
no canonicalization or comparison defined, which I think you'd agree  
would be "interesting".

I decided to avoid these registrations, but note that the actual  
syntax of the registry remains UTF-8, it's only the registration  
procedures that are restricted - and note that I've explicitly  
suggested that a future revision might change that.

FWIW, I also live somewhere where the lack of diacriticals would  
cause problems for local registrations, so I'm not unaware of the  
issues. My gut feeling remains, though, that as a first step an  
ASCII-only registry that's properly cleaned up and defined is more  
useful than a further delay.

> Minor issues:
> 
> - I think this document should update ACAP (RFC 2244). This should  
> be visible in the front page, so that the RFC Editor records an  
> update to RFC 2244.
> 

These look reasonable, thanks.

Dave.

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Thu, 21 Oct 2010 10:46:16 +0200

Hi Dave:

Some inline comments.

> no canonicalization or comparison defined, which I think you'd agree

I have several questions on the above statement. I hope you can elaborate 
a bit more.

- Is canonicalization or comparison required for the registry itself or 
for the protocols which use the registry?

- Can you indicate what is the real need of canonicalization? I mean, is 
it for avoiding duplication of vendor names in the registry, or for usage 
by the protocols (but what for)?

> suggested that a future revision might change that.

This does not help me. If I want to register a vendor name that includes 
non-ASCII characters, my registration will be rejected.

BR,

     Miguel

-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 21 Oct 2010 09:55:06 +0100

Hi Miguel,

Miguel A. Garcia wrote:

> I have several questions on the above statement. I hope you can 
> elaborate a bit more.
>
> - Is canonicalization or comparison required for the registry itself

Not under the current rules specified in ACAP (RFC 2244).

> or for the protocols which use the registry?

No.

> - Can you indicate what is the real need of canonicalization? I mean, 
> is it for avoiding duplication of vendor names in the registry, or for 
> usage by the protocols (but what for)?

If there is an accented character, there are multiple ways of encoding 
this in UTF-8. So one needs to have consistent rules for how to encode this.

> This does not help me. If I want to register a vendor name that 
> includes non-ASCII characters, my registration will be rejected.

I think you have wrong expectations for how this registry is used. This 
might not be very clear in the document, but here is what Chris Newman 
(the original author of ACAP) wrote:

   The use of textual rather than numeric identifiers for vendors 
benefits engineers and
   operators who are diagnosing protocol problems by allowing them some 
possibility of
   identifying the origin of a vendor attribute without having to look 
it up in a registry
   (although that remains a necessary fallback). As such engineers and 
operators already
   have to be familiar with international technical English to diagnose 
textual protocol
   problems, the restriction to ASCII may help and is not believed to 
harm that intended
   use. Exposure of vendor attributes directly in end-user user 
interfaces was not an
   intended use of the registry.

So ACAP Ventor Tokens don't need to be human readable. They are similar 
to domain names (without IDN).