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

Barry Leiba <> Wed, 04 September 2019 15:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AE8B012087A; Wed, 4 Sep 2019 08:57:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.401
X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id J0XeUdhhOR0n; Wed, 4 Sep 2019 08:57:10 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1F5C612086C; Wed, 4 Sep 2019 08:57:10 -0700 (PDT)
Received: by with SMTP id r4so30056175iop.4; Wed, 04 Sep 2019 08:57:10 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=qIzstm2qvV2tIE3iH+ab+Joh8g+3W8Gy28UVCVgzAZ0=; b=gmz2Zfof7sSI7m/ba6F8YkFie79eY1H4+FKF2vqd7dIOB9c8JwgKG9PsMQAsnC9jMa 4pXpGKQteeeY/i2/xZXb3c9kSpa8v8llZQ/rSoYu1mmGyHR4T+E2VQ3q33b4uOAYJnt8 cnbUFvb+p6mYEo9LDTt86yfMGP9Nq7tgvSdNtUDtK561BQpeMCd792jddMFOYznGXNxm /e8fsFLf7OXRIjBHMI3bN5+bXdXID8ZTtmUqwBLkHpSQaKEUg1TQM4mwDscPuC+gJoyo ZtRujLmbAbDiNnvXvK8OTqMSByMdayz48EdW45/bjp55er1xkeDEHTcf7XCX7n5RGj8k Fo4A==
X-Gm-Message-State: APjAAAWMMVK11GF3SOfmr1t1Vot3W74jauodZb5QfztYmeGYyW0ESkvQ 4NAQBiymllhDnSU3RFj5jT3GPKzkIfhLkj+xtQQ=
X-Google-Smtp-Source: APXvYqw4sp7v+2OBBjC7Exttnt38YokQfICYrD0NGSL9T9ePXLCrXwWcTWhl1dgJd6yqtsoLClOqg8ZMgGeROe/uDU8=
X-Received: by 2002:a5d:9b96:: with SMTP id r22mr3564855iom.17.1567612629024; Wed, 04 Sep 2019 08:57:09 -0700 (PDT)
MIME-Version: 1.0
References: <> <3B79ACC1CBCD8540E819481A@PSB> <>
In-Reply-To: <>
From: Barry Leiba <>
Date: Wed, 4 Sep 2019 11:56:57 -0400
Message-ID: <>
To: Paul Wouters <>
Cc: John C Klensin <>, IETF SecDir <>,, IESG <>,
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
Subject: Re: [secdir] Secdir last call review of draft-klensin-idna-rfc5891bis-05
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 04 Sep 2019 15:57:12 -0000

Hi, Paul, and let me add my thanks for your careful review of a rather
esoteric document.

Just on two points, and generalizing them:

> >> 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.

This has come up often.  As a text style thing, I know that John
prefers not to have the citation as part of the text.  It's the
difference between "As [RFC5891] says, ...," and "As the IDNA Protocol
[RFC5891] says, ...."  I mostly agree with John on this, from a
stylistic point of view, but accept (and even embrace) the reality
that many people like the former.  But style aside, Paul, your issue
is more about convenience to the reader, and that's an important
thing.  Clearly, there's no direct difference, simply from a "reading
the text" angle, between "RFC 5891" and "[RFC5891]".  This is,
therefore, an issue of tooling.  If we should change the HTML
rendering so that "RFC 5891" or "RFC5891" were as readily clickable as
"[RFC5891]", this would simply not be a problem, right?  Assuming
that, I think I will have a conversation with the tools team: we
should just do it.

> >>      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.

Yes, lots of discussion, yes, we'll leave it as it is for this case.  But...

In the general case, I actually rail *against* "SHOULD X, but MAY Y",
because I think they're contradictory: doing Y is not an entirely
optional choice (and MAY is too flaky anyway, and doesn't work here).
My strong preference is for using the following:
- MUST do X unless <condition>, in which case MUST do Y.
- MUST do X unless <condition>, in which case SHOULD do Y.
- MUST do X unless <condition>, in which case implementations generally do Y.
- SHOULD do X.  <explanation>

I note that in the last case, you already have an out, if you have a
good reason not to do X and understand the interoperability or
security implications.  But I think that most SHOULDs ought to include
an explanation of why it's "SHOULD" (and not MAY or MUST), what the
implications are, and what is done otherwise.  That explanation
doesn't need to have BCP 14 key words in it, and it probably detracts
from it if it does, at least much of the time.

Perhaps an exception to that last is if there are only, say, two
options, and one is strongly preferred from an
interoperability/security point of view.  Then, "SHOULD do X, but if
you don't do X you MUST do Y."  Or maybe "MUST do X or Y, and SHOULD
do X."

(BTW, I also think that "MAY do X" is useful only in certain
circumstances.  It's useful to alert one side that something might
happen that could otherwise be unexpected ("The server MAY close the
connection without warning."), and for clarity in certain situations
("The client MAY include multiple instances of X.").  It's not good
for things like, "The client MAY set the FARBLE bit to indicate that
it is farbling."  Well, yes, one presumes that's what the FARBLE bit
is for.)