Subject: Re: [Gen-art] Gen-ART LC Review of draft-montemurro-gsma-imei-urn-16

From: Alexey Melnikov <[email-masked]>
Date: Mon, 20 Jan 2014 11:26:04 +0000

On 17/09/2013 17:15, Andrew Allen wrote:
> Alexy
>
> Thank you for the review.
>
> My responses below prepended with [AA]
>
> Andrew
>
> -----Original Message-----
> From: Alexey Melnikov [mailto:[email-masked]]
> Sent: Thursday, August 08, 2013 6:56 AM
> To: [email-masked]
> Cc: <[email-masked]> Team
> Subject: Gen-ART LC Review of draft-montemurro-gsma-imei-urn-16
>
> I am the assigned 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 Last Call comments you may receive.
>
> Document:  draft-montemurro-gsma-imei-urn-16
> Reviewer: Alexey Melnikov	
> Review Date: 2013-08-08
> IETF LC End Date: 2013-08-16
>
> Summary: This draft is ready for publication as an Informational document (with nits).
>
> Major issues:
>
> -- None
>
> Minor issues:
>
> In 3.1:
>
> Rules for Lexical Equivalence:
>         Two GSMA IMEI URNs are equivalent if they have the same "imeival"
>         value, and the same gsma-specifier-params values in the same
>         sequential order, with the exception that the gsma-specifier-param
>         "vers=0" is to be ignored for the purposes of comparison.  All of
>         these comparisons are to be case-insensitive.
>
>         Any identifier in GSMA namespaces can be compared using the normal
>         mechanisms for percent-encoded UTF-8 strings.
>
> UTF-8 reference (RFC 3629) is missing here.
>
> [AA] Will add the RFC 3629 reference
In -19 I see:

3.  Namespace Registration Template

    Rules for Lexical Equivalence:

       Any identifier in 'gsma' NSS can be compared using the normal
       mechanisms for percent-encoded UTF-8 strings (see RFC 3629 [10]) .

The reference should be [8], not [10]. This just demonstrates why 
numeric references are a bad idea ;-).
> A minor point:
>
> 10.2.  Informative references
>
>      [8]   Crocker, D. and P. Overell, "Augmented BNF for Syntax
>            Specifications: ABNF", STD 68, RFC 5234, January 2008.
>
> This reference is Normative, because it is required to be understood in order to interpret ABNF syntax.
>
> [AA] As indicated in an earlier response I will make this normative