Re: [regext] WG LAST CALL: draft-ietf-regext-rfc7483bis

[James Galvin <[e-mail]>]

The WGLC for this document was scheduled to end today.  While there is 
support to move the document forward there are two minor comments that 
have been raised during the last call.

The chairs would like to hear from other working group members as to 
what to do with these comments.  Rather than close the last call and 
risk another last call, we are extending this last call for another 
week.  If we can come to a consensus as to how to proceed before the end 
of last call than the document can stay on track to be submitted to the 
IESG after the last call.

The WG last call will end at close of business on Friday, 9 October 
2020.



Here are the comments as seen on the mailing list.  Please respond with 
your suggestions regarding these two comments.



James Gould:

I have one item to bring up with draft-ietf-regext-rfc7483bis, which is 
associated with Section 5.1 “The Entity Object Class”.   The jCard 
"version" and "fn" members are required according to RFC 6350, which 
poses an issue if a contact name does not exist or needs to be redacted. 
  To address this case, I recommend adding a sentence to the end of 
section 3 "Common Data Types":

Contact information is defined using jCards as described in [RFC7095].  
The “version” and “fn” members are required according to 
[RFC6350], where an empty “fn” member MAY be used when the contact 
name does not exist or is redacted.

Two response have been offered:

Scott Hollenbeck:

I'd like to see some discussion of this suggestion. If one understands 
the normative references, the suggestion is already implicitly 
addressed. There may be some value in describing this situation 
explicitly since it came up in the ICANN gTLD implementation context, 
but so others think this clarification is necessary?

Jasdip Singh:

Seems if the RDAP profile for the DNRs 
(https://www.icann.org/resources/pages/rdap-operational-profile-2016-07-26-en) 
could clarify this, the spec could be left as-is.



Mario Loffredo:

The document does not contain any requirement or recommendation about 
when returning ldhName and unicodeName values. However, the examples 
seem to convey the idea that ldhName must  always be returned and 
unicodeName must be returned in case of an IDN.

No responses yet.



Thanks!

Antoin and Jim





On 18 Sep 2020, at 9:52, Antoin Verschuren wrote:

> The following working group document is believed to be ready for 
> submission to the IESG for publication as a standards track document:
>
> https://datatracker.ietf.org/doc/draft-ietf-regext-rfc7483bis/
>
> This WG last call will end at close of business, Friday, 2 October 
> 2020.
>
> Please review this document and indicate your support (a simple 
> “+1” is sufficient) or concerns with the publication of this 
> document by replying to this message on the list.
>
> The document shepherd for this document is Jasdip Singh.
>
> Regards,
>
> Jim and Antoin
>
>
>
>
>
>
>
> _______________________________________________
> regext mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/regext