Dear Alexey,
Thanks for your review. I have listed the reference in the following text. The 
references will be applied to other part in the document. Please see my 
feedbacks inline with [Linlin].
 
Regards,
Linlin


Linlin Zhou
 
From: Alexey Melnikov
Date: 2018-10-24 20:42
To: The IESG
CC: regext-chairs; pieter.vandepitte; draft-ietf-regext-org; regext
Subject: [regext] Alexey Melnikov's No Objection on draft-ietf-regext-org-11: 
(with COMMENT)
Alexey Melnikov has entered the following ballot position for
draft-ietf-regext-org-11: No Objection
 
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
 
 
Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.
 
 
The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-regext-org/
 
 
 
----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------
 
This is a well written document, but I am concerned about missing references
for various syntactic elements that you use. Having proper references will save
developers time and will improve interoperability. The same issue in at least 3
places in the document, I am mentioning the first one below.
 
In 4.1.1:
 
   o  An OPTIONAL <org:reason> element that may be provided when an
      object cannot be provisioned.  If present, this element contains
      server-specific text to help explain why the object cannot be
      provisioned.  This text MUST be represented in the response
      language previously negotiated with the client; an OPTIONAL "lang"
 
Please either point to the Language tag RFC 5646/BCP 47 or point to another RFC
which defines the "lang" attribute.
[Linlin] ...an OPTIONAL "lang" attribute as defined in [RFC 5646] MAY be 
present... 
 
      attribute MAY be present to identify the language if the
      negotiated value is something other than the default value of
      "en"(English).
 
4.1.2.  EPP <info> Command
 
   o  Zero to two <org:postalInfo> elements that contain postal-address
      information.  Two elements are provided so that address
      information can be provided in both internationalized and
      localized forms; a "type" attribute is used to identify the two
      forms.  If an internationalized form (type="int") is provided,
      element content MUST be represented in a subset of Unicode in the
      range U+0020 - U+007E.  If a localized form (type="loc") is
      provided, element content MAY be represented in unrestricted UTF-
      8.  The <org:postalInfo> element contains the following child
      elements:
 
[snip]
 
         +  An <org:cc> element that contains the organization's country
            code.
 
Please add the correct reference for country codes. I believe you want to
reference D country codes from ISO 3166. (There are also alpha-3 country
codes.)
 
Alternative you can just reference a section from RFC 5733.
[Linlin]  An <org:cc> element that contains the alpha-2 organization's country 
code. The detailed format of this element is described in section 2.4.3 of RFC 
5733.
 
   o  An OPTIONAL <org:email> element that contains the organization's
      email address.
 
Please point to specific format for email addresses (there is RFC 5321 format
and RFC 5322 format. They are not identical.) Alternative you can just
reference a section from RFC 5733.
[Linlin] An OPTIONAL <org:email> element that contains the organization's 
email address. The detailed format of this element is described in section 2.6 
of RFC 5733.
 
   o  An OPTIONAL <org:url> element that contains the URL to the website
      of the organization. 
 
Please add a reference to RFC 3986 or to one of HTTP RFCs if you want to
restrict this to https: or http:
[Linlin] An OPTIONAL <org:url> element that contains the URL to the website of 
the organization. The detailed format of this element is described in RFC 3986.
 
One possible way of addressing all of the above is to add a few sentences with
references to the "Conventions Used in This Document" section.
 
 
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Reply via email to