Re: WGLC Announcement for draft-ietf-tsvwg-iana-ports-08 - 26th November2010

"t.petch" <ietfc@btconnect.com> Fri, 03 December 2010 16:01 UTC

Return-Path: <ietfc@btconnect.com>
X-Original-To: tsvwg@core3.amsl.com
Delivered-To: tsvwg@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 210BF28C113 for <tsvwg@core3.amsl.com>; Fri, 3 Dec 2010 08:01:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.055
X-Spam-Level:
X-Spam-Status: No, score=-2.055 tagged_above=-999 required=5 tests=[AWL=-0.056, BAYES_00=-2.599, J_CHICKENPOX_15=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wm-OLcE7ebhp for <tsvwg@core3.amsl.com>; Fri, 3 Dec 2010 08:01:45 -0800 (PST)
Received: from mail.btconnect.com (c2bthomr14.btconnect.com [213.123.20.132]) by core3.amsl.com (Postfix) with ESMTP id C1ED528C107 for <tsvwg@ietf.org>; Fri, 3 Dec 2010 08:01:44 -0800 (PST)
Received: from host81-156-71-67.range81-156.btcentralplus.com (HELO pc6) ([81.156.71.67]) by c2bthomr14.btconnect.com with SMTP id AWV97715; Fri, 03 Dec 2010 16:03:00 +0000 (GMT)
Message-ID: <008301cb92fa$dba69d80$4001a8c0@gateway.2wire.net>
From: "t.petch" <ietfc@btconnect.com>
To: Magnus Westerlund <magnus.westerlund@ericsson.com>
References: <4CCBD067.60206@erg.abdn.ac.uk> <000201cb7b49$212cbc00$4001a8c0@gateway.2wire.net> <4CD159B0.2050906@ericsson.com> <005901cb7b6e$80bbc740$4001a8c0@gateway.2wire.net> <4CF65F37.8050400@ericsson.com>
Subject: Re: WGLC Announcement for draft-ietf-tsvwg-iana-ports-08 - 26th November2010
Date: Fri, 03 Dec 2010 15:22:25 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0302.4CF914B3.0186, actions=tag
X-Junkmail-Status: score=10/50, host=c2bthomr14.btconnect.com
X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0207.4CF914B4.01B4, ss=1, fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=single engine
X-Junkmail-IWF: false
Cc: tsvwg list <tsvwg@ietf.org>
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tsvwg>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 03 Dec 2010 16:01:46 -0000

----- Original Message -----
From: "Magnus Westerlund" <magnus.westerlund@ericsson.com>
To: "t.petch" <ietfc@btconnect.com>
Cc: "tsvwg list" <tsvwg@ietf.org>
Sent: Wednesday, December 01, 2010 3:44 PM
>
> The author team has now edited this issue into our draft version.
> However, after some consideration of IANAs language use we have ended up
> using "assign" and assignment instead of allocation. Then we use
> "assignment request" or "assignment procedure" depending on context. I
> hope that is still satisfactory.

Yes, it is a massive improvement in terms of clarity and readability; thanks for
that.

Tom Petch



> Magnus
>
> t.petch skrev 2010-11-03 16:47:
> > ----- Original Message -----
> > From: "Magnus Westerlund" <magnus.westerlund@ericsson.com>
> > To: "t.petch" <ietfc@btconnect.com>
> > Cc: "tsvwg list" <tsvwg@ietf.org>
> > Sent: Wednesday, November 03, 2010 1:46 PM
> >
> >> Hi Tom,
> >>
> >> Apparently your comment from January about the mix of terms was missed
> >> and not addressed.
> >>
> >> If I understand the English terms correctly, what we are describing that
> >> IANA should do is Allocation, i.e. set aside identifiers for particular
> >> usages. We are not giving over the number space to the ones that
> >> request, thus Assignment would be wrong?
> >>
> >> I think we can mostly eliminate one of the terms assignment and
> >> allocation. I think we will have more difficult to get rid of
> >> registration. My personal thinking on this is at least the following
> >> relationship between the terms: A Registrant performs a Registration
> >> (process or request) so that IANA can perform an Allocation of a service
> >> name and possibly ports.
> >
> > Magnus
> >
> > That would address my concern. As you say, assign has more of an overtone
> > of a legal transfer of ownership, which allocate does not (even if my
dictionary
> > defines allocate as assign:-(  There is a lot of assignation in the current
I-D
> > but
> > I think that most of it should be changed.
> >
> > I like too the idea that registration is the request, and that IANA
allocates,
> > and
> > again, there is a lot of registration and I think that most of it should be
> > changed.
> >
> > It is unfortunate that the end result of an allocation by IANA is a registry
but
> > I
> > do not think that that can be helped:-(   Whatever terminology we agree on,
> > I think that the I-D should spell it out early on.
> >
> > I did scan a variety of I-Ds with IANA actions and see IANA allocating,
> > registering
> > and assigning values in registries, with perhaps the last as the most
common,
> > but that does
> > not make it the right choice for me.
> >
> > Tom Petch
>
>
> --
>
> Magnus Westerlund
>
> ----------------------------------------------------------------------
> Multimedia Technologies, Ericsson Research EAB/TVM
> ----------------------------------------------------------------------
> Ericsson AB                | Phone  +46 10 7148287
> Färögatan 6                | Mobile +46 73 0949079
> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
> ----------------------------------------------------------------------