Re: Last Call: <draft-ietf-tsvwg-port-use-06.txt> (Recommendations for Transport Port Number Uses) to Best Current Practice

Joe Touch <touch@isi.edu> Fri, 16 January 2015 19:27 UTC

Return-Path: <touch@isi.edu>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 598D81B2A97; Fri, 16 Jan 2015 11:27:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.91
X-Spam-Level:
X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t-Z5w9sQxqJp; Fri, 16 Jan 2015 11:27:16 -0800 (PST)
Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26A301B2AC7; Fri, 16 Jan 2015 11:27:14 -0800 (PST)
Received: from [10.123.102.85] (usc-secure-wireless-206-085.usc.edu [68.181.206.85]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id t0GJQmxx026491 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 16 Jan 2015 11:26:51 -0800 (PST)
Message-ID: <54B965F9.6090704@isi.edu>
Date: Fri, 16 Jan 2015 11:26:49 -0800
From: Joe Touch <touch@isi.edu>
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: Alexey Melnikov <alexey.melnikov@isode.com>, ietf@ietf.org
Subject: Re: Last Call: <draft-ietf-tsvwg-port-use-06.txt> (Recommendations for Transport Port Number Uses) to Best Current Practice
References: <20141208235619.4442.37821.idtracker@ietfa.amsl.com> <54A990F4.9040509@isode.com> <54B95EDC.9000905@isi.edu> <54B9639F.7020905@isode.com>
In-Reply-To: <54B9639F.7020905@isode.com>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/a0enGag06DhpPRu0-km_zj6JOvs>
Cc: tsvwg@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 16 Jan 2015 19:27:21 -0000

Hi, Alexey,

On 1/16/2015 11:16 AM, Alexey Melnikov wrote:
> Hi Joe,
> 
...
> My concerns is that BCP are commonly used by ADs to enforce compliance.
> So I am wondering why this document is not just Informational?

AFAIR, the WG wanted it to be BCP to be a stronger recommendation to
protocol designers than would be an Informational doc.

However, the way expert review and the appeals process already allows
ADs to either use BCPs or override them anyway, so I don't see this as
unduly constraining them. Besides, all sorts of docs - including
standards-track - are contradictory, so there's no one way to ensure
they're all followed.

...
>>> In 7.4:
...
>>> Inserting "solely" before "by a browser" would address my concern.
>> Would "primarily" also work? It's hard to argue "solely" even for
>> conventional web access.
>
> Yes, "primarily" is actually better.

OK. Will do.

>>> In 7.4:
>>>
>>>     Note however that a new service might not be eligible for IANA
>>>     assignment of both an insecure and a secure variant of the same
>>>     service, and similarly IANA might be skeptical of an assignment for
>>>
>>> I don't think use of wording like "IANA might be skeptical" is correct
>>> here, because IANA doesn't define policy on this. IETF does. So let's
>>> call things with right names and don't misuse "IANA" here.
>>
>> The document isn't written by IANA. We recommend to IANA, and IANA makes
>> a decision that the IESG can override. I don't think it's outside the
>> scope of the doc to indicate this context.
>
> Actually I disagree. IANA is just following procedure prescribed by
> IETF. Experts are not really acting as advisors (although in practice
> there is always a dialogue, which is as it should be).

IANA doesn't have to agree with expert reviewer recommendations. There
isn't anything binding that, though - as you note - there's a dialogue
and it's not an issue in practice.

>> Would it be preferable to say that "applications asking for both...
>> might not be approved when..."?
>
> Yes.

OK - will do.

>>>     an insecure port number for a secure service. In both cases,
>>>     security of the service is compromised by adding the insecure port
>>>     number assignment.
>>>
>>> Similarly (in the same section): "IANA currently permits ..."
>> Same solution here?
>
> Sure.

OK - will do.

Joe