Re: [secdir] Secdir last call review of draft-klensin-idna-rfc5891bis-05

[Paul Wouters <[e-mail]>]

On Tue, 3 Sep 2019, John C Klensin wrote:

> Subject: Re: Secdir last call review of draft-klensin-idna-rfc5891bis-05

[ Only addressing the document review items in this email, not the SecDir review process ]


>> Issue:
>>
>> It seems the document asks for the IANA Consideration section
>> to be removed. Instead, it should keep the Section but use the
>> text along the lines of  " This document has no IANA
>> actions.". This helps people who are looking through various
>> RFC's to find IANA considerations.
>
> Until and unless the rules are changed to require IANA
> Considerations sections in all IETF Stream documents, this is a
> judgment call.  Your preference is noted but at least this
> author believes that the omission of an essentially trivial
> statement is more helpful to many users then including it and
> keeps documents shorter.

I understand it is a matter of preference. I find it takes me less time
to go through the document's Table of Contents to find the IANA Section
that says "nothing to see here, move along" than it is for me to try
and find the non-existing IANA Section.

>> Minor issues:
>>
>> I find the term "For-profit domain" very confusing as .pizza
>> is a very much for profit domain. Normally, the terms "Generic
>> domain" and "Brand domain" although I guess the latter is
>> usually avoided in written text. While the term is described
>> to mean a Generic Domain, I think it would be better to use
>> Generic domain instead of For-profit domain.
>
> "For-profit" was chosen after multiple discussions about the
> best term and was chosen, in part, because it is not in common
> use.

Okay. Again personally, I think as a person who has spend time in
IETF and ICANN that this term is less clear, but if the WG and
author has spent considerable time on this discussion already, then
there is no need to revisit this based on my single added opinion.

>>   Registries choosing to make exceptions -- allow code points
>> that   recommendations such as the MSR do not allow -- should
>> make such   decisions only with great care and only if they
>> have considerable   understanding of, and great confidence in,
>> their appropriateness.
>>
>> This paragraph seems really to say "Registries SHOULD NOT make
>> exceptions" and seems a good place for some RFC 2119 wording.
>
> While the language was a compromise -- Asmus is inclined to be
> somewhat more restrictive and directive than I am -- "SHOULD
> NOT" is definitely not appropriate.

If this has been discussed and the result of a compromise, again
my one voice shouldn't matter anymore in this case so feel free
to leave as is. Although personally I do think you could have
used "SHOULD NOT" followed by a "MAY" to give this a little more
weight (especially as the document talks about outsiders/implementors
getting things wrong). But this is not important enough to re-open
an old discussion.

>> I find the term "registry" in this document confusing, as it

> See above.

Same here, that's fine.

>> [ID.draft-klensin-idna-unicode-review] is in progress.  Its
>> status    should be checked in conjunction with application of
>> the present    specification.
>>
>> I think this is meant as informational to the RFC Editor ?
>> Perhaps these documents should go out as a cluster?
>
> Yes, it is informational to the RFC Editor.  And, yes, it is not
> an accident that the two documents went out for Last Call at the
> same time and are being evaluated concurrently.  My hope is to
> see both to them in the RFC Editor's hands at the same time,
> whether they are explicitly handled as a cluster or not.

Good.

>> Note I find some documents are references within [square
>> brackets] but not all of them, even some RFC's are in brackets
>> and others are not. Please make this consistent.
>
> I think you will find that all documents are cited (with the
> square brackets) at least once.  After many discussions over the
> years with the RFC Editor

That's fine then too. I personally prefer to have it clickable, so
if at the third time of an RFC being mentioned I go like "okay, I
should really read this" and I can click on it on that 3rd instance.
But I also understand the document shouldn't become a Christmas tree
of links.

> On checking on your comment, I did catch one instance of a
> reference in square bracket that was not properly set up as a
> citation.  It is now fixed in the working version but, unless
> the AD directs otherwise, I'm not going to repost for this
> rather trivial problem that I'm confident the RFC Editor would
> have caught.

That's fine, thanks.

>>      registries SHOULD normally consult
>>
>> Either use "SHOULD" or "normally", not both? It's a little odd.
>
> This document is a little odd in the sense that, in a more
> perfect world, it should be completely unnecessary.

For me as a programmer, I prefer to read SHOULDs followed by MAY
to relay these kind of "should normally do X". It is just more
formal and thus easier for implementers to follow programatically.
But again, if this has seen lots of discussion already, please
feel free to leave as is.

>>    to fully satisfy the mandate set out above
>>
>> Instead of mandate, which is a bit generic and confusing, why
>> not refer to the mentioned "IAB guidance", which I think it is
>> referring to ?
>
> Because it isn't referring to the IAB guidance or, more
> specifically, is referring to parts of it and some other things.
> Suggested better language would be welcome, again subject to the
> request/ suggestion above.

Now this does seem like a real issue. After reading it a few times,
I included that "mandate" meant the IAB guidance, and now you are
telling me it actually does not. So that just confirms the use of
"the mandate set out above" is actually not at all clear and should
be clarified.

>
>>     may provide useful guidance.
>
>
>> Remove the word "may"
>
> "may" was intentional.

Okay.

So in conclusion, all my comments/questions are addressed, except for
the mandate issue. It is not big enough to block the document for, but
I think it would be useful to clarify further.

Paul