Re: [regext] Alexey Melnikov's No Objection on draft-ietf-regext-org-11: (with COMMENT)

[Alexey Melnikov <[e-mail]>]

Hi Linlin,
Your proposed changes look good to me!

Thank you,
Alexey

> On 25 Oct 2018, at 08:37, Linlin Zhou <[e-mail]> wrote:
> 
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/regext