[IANA #821110] Application for a Port Number and/or Service Name "ceph" (fwd)

[IANA #821110] Application for a Port Number and/or Service Name "ceph" (fwd)

[Sage Weil]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 573 bytes --]

So, I picked 6789 way back in commit 
dc38de9b14c5386f9f446124ca6d6673eb8a1e20 because it was unused according 
to nmap-services.  It's there now, in use by smc-https (whatever that is), 
and says it was registered in 2002.  I guess the nmap-services file I 
looked at at the time was out of date?

In any case, if we want an IANA assigned number, we'll need to change it.  

We should be able to make a transition reasonably painless by making 
clients try both ports when none is specified for some period.

I'm assuming it's worth the effort... what do you think?

sage

[-- Attachment #2: Forwarded Message --]
[-- Type: MESSAGE/RFC822, Size: 7145 bytes --]

Return-Path: <iana-shared@icann.org>
X-Original-To: sage@cobra.newdream.net
Delivered-To: sage@cobra.newdream.net
Received: from destro.newdream.net (destro.newdream.net [66.33.216.68])
	by cobra.newdream.net (Postfix) with ESMTP id 491E38021C
	for <sage@cobra.newdream.net>; Wed, 29 Apr 2015 08:54:31 -0700 (PDT)
Received: by destro.newdream.net (Postfix)
	id 15F1B1209D9; Wed, 29 Apr 2015 08:54:31 -0700 (PDT)
Delivered-To: sage@destro.newdream.net
Received: from diehard.dreamhost.com (caiajhbdcbfh.dreamhost.com
	[208.97.132.157])
	by destro.newdream.net (Postfix) with ESMTP id 1193C1209C8
	for <sage@newdream.net>; Wed, 29 Apr 2015 08:54:31 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1])
	by diehard.dreamhost.com (Postfix) with ESMTP id 0CA5717BE005
	for <sage@newdream.net>; Wed, 29 Apr 2015 08:54:31 -0700 (PDT)
X-DH-Virus-Scanned: Debian amavisd-new at diehard.dreamhost.com
X-Spam-Flag: NO
X-Spam-Score: 0.905
X-Spam-Level: 
X-Spam-Status: No, score=0.905 tagged_above=-999 required=999
	tests=[MISSING_HEADERS=0.915, T_RP_MATCHES_RCVD=-0.01]
	autolearn=disabled
Received: from terminator.dreamhost.com ([208.97.132.17])
	by localhost (diehard.dreamhost.com [208.97.132.157]) (amavisd-new,
	port 10024) with ESMTP id rOdgMMnh7U1B for <sage@newdream.net>;
	Wed, 29 Apr 2015 08:54:30 -0700 (PDT)
Received: from smtp1.lax.icann.org (smtp01.icann.org [192.0.33.81])
	by terminator.dreamhost.com (Postfix) with ESMTP id A0F202930011
	for <sage@newdream.net>; Wed, 29 Apr 2015 08:54:30 -0700 (PDT)
Received: from request3.lax.icann.org (request1.lax.icann.org [10.32.11.221])
	by smtp1.lax.icann.org (8.13.8/8.13.8) with ESMTP id t3TFsUXA017813
	for <sage@newdream.net>; Wed, 29 Apr 2015 15:54:30 GMT
Received: by request3.lax.icann.org (Postfix, from userid 48)
	id 60565C205B8; Wed, 29 Apr 2015 15:54:30 +0000 (UTC)
RT-Owner: pearl.liang
Subject: [IANA #821110] Application for a Port Number and/or Service Name
	"ceph"
From: "Pearl Liang via RT" <iana-ports@iana.org>
Reply-To: iana-ports@iana.org
In-Reply-To: <201504272158.t3RLwdEE026988@smtp1.lax.icann.org>
References: <RT-Ticket-821110@icann.org>
	<201504272158.t3RLwdEE026988@smtp1.lax.icann.org>
Message-ID: <rt-4.2.9-5772-1430322870-91.821110-7-0@icann.org>
X-RT-Loop-Prevention: IANA
X-RT-Ticket: IANA #821110
X-Managed-BY: RT 4.2.9 (http://www.bestpractical.com/rt/)
X-RT-Originator: pearl.liang@icann.org
CC: sage@newdream.net
Content-Type: text/plain; charset="utf-8"
X-RT-Original-Encoding: utf-8
Precedence: bulk
Date: Wed, 29 Apr 2015 15:54:30 +0000
MIME-Version: 1.0
X-Spambayes-Classification: ham; 0.00
Content-Transfer-Encoding: quoted-printable


Dear Sage Weil:

Thank you for submitting this application.    We have one question regard=
ing
the proposed port number:

Desired Port Number: [6789]

You explained that you've been using the number for years:

8. Please explain the state of development of your protocol.
[The protocol was initially developed in the 2008-2010 timeframe and has =
been deployed in production systems for the last 3-4 years. The existing =
protocol versioning and other features have proven effective to handle al=
l of the protocol and system changes we have dealt with over that period.=
]

This port number has already been assigned to other service, so you need
to pick another number.  As noted in the online template form, unassigned=
=20
service names and port numbers should not be used prior to assignment.=20

When we receive your reply, we can continue the processing of the request=
.

Thank you,

Pearl Liang
ICANN


On Mon Apr 27 21:58:40 2015, sage@newdream.net wrote:
>=20
> Application for a Port Number and/or Service Name
>=20
> Assignee: Sage Weil <sage@newdream.net>
> Contact Person: Sage Weil <sage@newdream.net>
>=20
> Resource Request:
>=20
> [x] Port Number
> [x] Service Name
>=20
> Transport Protocols:
>     [x] TCP
>     [ ] UDP
>     [ ] SCTP
>     [ ] DCCP
>=20
> Service Code:         []
> Service Name:         [ceph]
> Desired Port Number:  [6789]
> Description:          [Ceph monitor]
>=20
> Reference:
> [The Ceph storage cluster monitor daemon runs on a known port and is
> responsible for orchestrating and arbitrating access to Ceph storage
> services.  All other components of the system use dynamically port
> numbers and do not require a fixed assignment.
>=20
> The protocol is a TCP based message passing protocol.]
>=20
> Defined TXT Keys:
>=20
> 1.  If broadcast/multicast is used, how and what for?
> [n/a]
>=20
> 2.  If UDP is requested, please explain how traffic is limited, and
> whether the
>     protocol reacts to congestion.
> [n/a]
>=20
> 3.  If UDP is requested, please indicate whether the service is solely
>     for the discovery of hosts supporting this protocol.
> [n/a]
>=20
> 4.  Please explain how your protocol supports versioning.
> [There is an initial handshake that includes protocol feature bits
> supported.  After the exchange either end can choose to adjust the
> format of subsequent message accordingly (e.g., for backward
> compatibility), adjust its behavior, or opt to disconnect entirely
> with an error message.]
>=20
> 5.  If your request is for more than one transport, please explain in
>     detail how the protocol differs over each transport.
> [n/a]
>=20
> 6.  Please describe how your protocol supports security. Note that
> presently
>     there is no IETF consensus on when it is appropriate to use a
> second port
>     for an insecure version of a protocol.
> [Part of the early handshake with monitors provides for mutual
> authentication of client and server using a shared secret.  The client
> is then provided capabilities that are used when interacting with
> other Ceph services in the system.  The overall model is based on
> Kerberos and uses a similar cryptographic scheme.]
>=20
> 7.  Please explain why a unique port assignment is necessary as
> opposed to a
>    port in range (49152-65535) or existing port.
> [The Ceph monitor is the only service in the system that runs on a
> fixed port as it is used for initial client authentication and to
> learn the addresses of other services in the cluster (which all
> dynamically allocate ports within a range).]
>=20
> 8.  Please explain the state of development of your protocol.
> [The protocol was initially developed in the 2008-2010 timeframe and
> has been deployed in production systems for the last 3-4 years.  The
> existing protocol versioning and other features have proven effective
> to handle all of the protocol and system changes we have dealt with
> over that period.]
>=20
> 9.  If SCTP is requested, is there an existing TCP and/or UDP service
> name or
>     port number assignment? If yes, provide the existing service name
> and port number.
> [n/a]
>=20
> 10.  What specific SCTP capability is used by the application such
> that a
>     user who has the choice of both TCP (and/or UDP) and SCTP ports
> for
>     this application would choose SCTP? See RFC 4960 section 7.1.
> [n/a]
>=20
> 11. Please provide any other information that would be helpful in
>     understanding how this protocol differs from existing assigned
> services.
> []



From: "Pearl Liang via RT" <iana-ports@iana.org>
Cc: sage@newdream.net
Subject: [IANA #821110] Application for a Port Number and/or Service Name "ceph"
Date: Wed, 29 Apr 2015 15:54:30 +0000
Message-ID: <rt-4.2.9-5772-1430322870-91.821110-7-0@icann.org>


Dear Sage Weil:

Thank you for submitting this application.    We have one question regarding
the proposed port number:

Desired Port Number: [6789]

You explained that you've been using the number for years:

8. Please explain the state of development of your protocol.
[The protocol was initially developed in the 2008-2010 timeframe and has been deployed in production systems for the last 3-4 years. The existing protocol versioning and other features have proven effective to handle all of the protocol and system changes we have dealt with over that period.]

This port number has already been assigned to other service, so you need
to pick another number.  As noted in the online template form, unassigned 
service names and port numbers should not be used prior to assignment. 

When we receive your reply, we can continue the processing of the request.

Thank you,

Pearl Liang
ICANN


On Mon Apr 27 21:58:40 2015, sage@newdream.net wrote:
> 
> Application for a Port Number and/or Service Name
> 
> Assignee: Sage Weil <sage@newdream.net>
> Contact Person: Sage Weil <sage@newdream.net>
> 
> Resource Request:
> 
> [x] Port Number
> [x] Service Name
> 
> Transport Protocols:
>     [x] TCP
>     [ ] UDP
>     [ ] SCTP
>     [ ] DCCP
> 
> Service Code:         []
> Service Name:         [ceph]
> Desired Port Number:  [6789]
> Description:          [Ceph monitor]
> 
> Reference:
> [The Ceph storage cluster monitor daemon runs on a known port and is
> responsible for orchestrating and arbitrating access to Ceph storage
> services.  All other components of the system use dynamically port
> numbers and do not require a fixed assignment.
> 
> The protocol is a TCP based message passing protocol.]
> 
> Defined TXT Keys:
> 
> 1.  If broadcast/multicast is used, how and what for?
> [n/a]
> 
> 2.  If UDP is requested, please explain how traffic is limited, and
> whether the
>     protocol reacts to congestion.
> [n/a]
> 
> 3.  If UDP is requested, please indicate whether the service is solely
>     for the discovery of hosts supporting this protocol.
> [n/a]
> 
> 4.  Please explain how your protocol supports versioning.
> [There is an initial handshake that includes protocol feature bits
> supported.  After the exchange either end can choose to adjust the
> format of subsequent message accordingly (e.g., for backward
> compatibility), adjust its behavior, or opt to disconnect entirely
> with an error message.]
> 
> 5.  If your request is for more than one transport, please explain in
>     detail how the protocol differs over each transport.
> [n/a]
> 
> 6.  Please describe how your protocol supports security. Note that
> presently
>     there is no IETF consensus on when it is appropriate to use a
> second port
>     for an insecure version of a protocol.
> [Part of the early handshake with monitors provides for mutual
> authentication of client and server using a shared secret.  The client
> is then provided capabilities that are used when interacting with
> other Ceph services in the system.  The overall model is based on
> Kerberos and uses a similar cryptographic scheme.]
> 
> 7.  Please explain why a unique port assignment is necessary as
> opposed to a
>    port in range (49152-65535) or existing port.
> [The Ceph monitor is the only service in the system that runs on a
> fixed port as it is used for initial client authentication and to
> learn the addresses of other services in the cluster (which all
> dynamically allocate ports within a range).]
> 
> 8.  Please explain the state of development of your protocol.
> [The protocol was initially developed in the 2008-2010 timeframe and
> has been deployed in production systems for the last 3-4 years.  The
> existing protocol versioning and other features have proven effective
> to handle all of the protocol and system changes we have dealt with
> over that period.]
> 
> 9.  If SCTP is requested, is there an existing TCP and/or UDP service
> name or
>     port number assignment? If yes, provide the existing service name
> and port number.
> [n/a]
> 
> 10.  What specific SCTP capability is used by the application such
> that a
>     user who has the choice of both TCP (and/or UDP) and SCTP ports
> for
>     this application would choose SCTP? See RFC 4960 section 7.1.
> [n/a]
> 
> 11. Please provide any other information that would be helpful in
>     understanding how this protocol differs from existing assigned
> services.
> []

Re: [IANA #821110] Application for a Port Number and/or Service Name "ceph" (fwd)

[Mark Nelson]

On 04/29/2015 12:02 PM, Sage Weil wrote:
> So, I picked 6789 way back in commit
> dc38de9b14c5386f9f446124ca6d6673eb8a1e20 because it was unused according
> to nmap-services.  It's there now, in use by smc-https (whatever that is),
> and says it was registered in 2002.  I guess the nmap-services file I
> looked at at the time was out of date?
>
> In any case, if we want an IANA assigned number, we'll need to change it.
>
> We should be able to make a transition reasonably painless by making
> clients try both ports when none is specified for some period.
>
> I'm assuming it's worth the effort... what do you think?

Yes, I think it's worth it.  Better now than when we are 10x bigger than 
<large storage vendor> right? ;)

Mark

>
> sage
>

Re: [IANA #821110] Application for a Port Number and/or Service Name "ceph" (fwd)

[Sage Weil]

On Wed, 29 Apr 2015, Mark Nelson wrote:
> On 04/29/2015 12:02 PM, Sage Weil wrote:
> > So, I picked 6789 way back in commit
> > dc38de9b14c5386f9f446124ca6d6673eb8a1e20 because it was unused according
> > to nmap-services.  It's there now, in use by smc-https (whatever that is),
> > and says it was registered in 2002.  I guess the nmap-services file I
> > looked at at the time was out of date?
> > 
> > In any case, if we want an IANA assigned number, we'll need to change it.
> > 
> > We should be able to make a transition reasonably painless by making
> > clients try both ports when none is specified for some period.
> > 
> > I'm assuming it's worth the effort... what do you think?
> 
> Yes, I think it's worth it.  Better now than when we are 10x bigger than
> <large storage vendor> right? ;)

Hmm, we could go for something < 1024 too, but that will make non-root 
ceph-mon's more annoying, I suspect.

http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=unassigned

sage

Re: [IANA #821110] Application for a Port Number and/or Service Name "ceph" (fwd)

[Robert LeBlanc]

I'd prefer >1024 if we expect to run non-root.

On Wed, Apr 29, 2015 at 11:34 AM, Sage Weil <sage@newdream.net> wrote:
> On Wed, 29 Apr 2015, Mark Nelson wrote:
>> On 04/29/2015 12:02 PM, Sage Weil wrote:
>> > So, I picked 6789 way back in commit
>> > dc38de9b14c5386f9f446124ca6d6673eb8a1e20 because it was unused according
>> > to nmap-services.  It's there now, in use by smc-https (whatever that is),
>> > and says it was registered in 2002.  I guess the nmap-services file I
>> > looked at at the time was out of date?
>> >
>> > In any case, if we want an IANA assigned number, we'll need to change it.
>> >
>> > We should be able to make a transition reasonably painless by making
>> > clients try both ports when none is specified for some period.
>> >
>> > I'm assuming it's worth the effort... what do you think?
>>
>> Yes, I think it's worth it.  Better now than when we are 10x bigger than
>> <large storage vendor> right? ;)
>
> Hmm, we could go for something < 1024 too, but that will make non-root
> ceph-mon's more annoying, I suspect.
>
> http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=unassigned
>
> sage
> --
> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [IANA #821110] Application for a Port Number and/or Service Name "ceph" (fwd)

[Joao Eduardo Luis]

On 04/29/2015 06:34 PM, Sage Weil wrote:
> On Wed, 29 Apr 2015, Mark Nelson wrote:
>> On 04/29/2015 12:02 PM, Sage Weil wrote:
>>> So, I picked 6789 way back in commit
>>> dc38de9b14c5386f9f446124ca6d6673eb8a1e20 because it was unused according
>>> to nmap-services.  It's there now, in use by smc-https (whatever that is),
>>> and says it was registered in 2002.  I guess the nmap-services file I
>>> looked at at the time was out of date?
>>>
>>> In any case, if we want an IANA assigned number, we'll need to change it.
>>>
>>> We should be able to make a transition reasonably painless by making
>>> clients try both ports when none is specified for some period.
>>>
>>> I'm assuming it's worth the effort... what do you think?
>>
>> Yes, I think it's worth it.  Better now than when we are 10x bigger than
>> <large storage vendor> right? ;)
> 
> Hmm, we could go for something < 1024 too, but that will make non-root 
> ceph-mon's more annoying, I suspect.
> 
> http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=unassigned
> 

35168 seems available (range 35007-35353).

And before someone thinks I'm on something, 35168 is the result of:

>>> p = 0
>>> for x in reversed('ceph'):
...  j = len(str(p))
...  if p == 0:
...   j = 0
...  p += (ord(x)-ord('a')+1)*pow(10,j)


Although definitely not as easy to remember (or type) as 6789 :(

  -Joao

p.s.: 31337 is also available ;)

Re: [IANA #821110] Application for a Port Number and/or Service Name "ceph" (fwd)

[Sage Weil]

On Wed, 20 May 2015, Joao Eduardo Luis wrote:
> On 04/29/2015 06:34 PM, Sage Weil wrote:
> > On Wed, 29 Apr 2015, Mark Nelson wrote:
> >> On 04/29/2015 12:02 PM, Sage Weil wrote:
> >>> So, I picked 6789 way back in commit
> >>> dc38de9b14c5386f9f446124ca6d6673eb8a1e20 because it was unused according
> >>> to nmap-services.  It's there now, in use by smc-https (whatever that is),
> >>> and says it was registered in 2002.  I guess the nmap-services file I
> >>> looked at at the time was out of date?
> >>>
> >>> In any case, if we want an IANA assigned number, we'll need to change it.
> >>>
> >>> We should be able to make a transition reasonably painless by making
> >>> clients try both ports when none is specified for some period.
> >>>
> >>> I'm assuming it's worth the effort... what do you think?
> >>
> >> Yes, I think it's worth it.  Better now than when we are 10x bigger than
> >> <large storage vendor> right? ;)
> > 
> > Hmm, we could go for something < 1024 too, but that will make non-root 
> > ceph-mon's more annoying, I suspect.
> > 
> > http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=unassigned
> > 
> 
> 35168 seems available (range 35007-35353).
> 
> And before someone thinks I'm on something, 35168 is the result of:
> 
> >>> p = 0
> >>> for x in reversed('ceph'):
> ...  j = len(str(p))
> ...  if p == 0:
> ...   j = 0
> ...  p += (ord(x)-ord('a')+1)*pow(10,j)

Heh, now I know you're on something!

What about CE4h = 3300?

sage


> Although definitely not as easy to remember (or type) as 6789 :(
> 
>   -Joao
> 
> p.s.: 31337 is also available ;)

Re: [IANA #821110] Application for a Port Number and/or Service Name "ceph" (fwd)

[Joao Eduardo Luis]

On 05/26/2015 09:30 PM, Sage Weil wrote:
> On Wed, 20 May 2015, Joao Eduardo Luis wrote:
>> On 04/29/2015 06:34 PM, Sage Weil wrote:
>>> On Wed, 29 Apr 2015, Mark Nelson wrote:
>>>> On 04/29/2015 12:02 PM, Sage Weil wrote:
>>>>> So, I picked 6789 way back in commit
>>>>> dc38de9b14c5386f9f446124ca6d6673eb8a1e20 because it was unused according
>>>>> to nmap-services.  It's there now, in use by smc-https (whatever that is),
>>>>> and says it was registered in 2002.  I guess the nmap-services file I
>>>>> looked at at the time was out of date?
>>>>>
>>>>> In any case, if we want an IANA assigned number, we'll need to change it.
>>>>>
>>>>> We should be able to make a transition reasonably painless by making
>>>>> clients try both ports when none is specified for some period.
>>>>>
>>>>> I'm assuming it's worth the effort... what do you think?
>>>>
>>>> Yes, I think it's worth it.  Better now than when we are 10x bigger than
>>>> <large storage vendor> right? ;)
>>>
>>> Hmm, we could go for something < 1024 too, but that will make non-root 
>>> ceph-mon's more annoying, I suspect.
>>>
>>> http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=unassigned
>>>
>>
>> 35168 seems available (range 35007-35353).
>>
>> And before someone thinks I'm on something, 35168 is the result of:
>>
>>>>> p = 0
>>>>> for x in reversed('ceph'):
>> ...  j = len(str(p))
>> ...  if p == 0:
>> ...   j = 0
>> ...  p += (ord(x)-ord('a')+1)*pow(10,j)
> 
> Heh, now I know you're on something!
> 
> What about CE4h = 3300?

I like it being easy to remember. :)

  -Joao

> 
> sage
> 
> 
>> Although definitely not as easy to remember (or type) as 6789 :(
>>
>>   -Joao
>>
>> p.s.: 31337 is also available ;)
>