Re: [port-srv-reg] Questions about the Port Template forms for the ports document actions

[Michelle Cotton <[e-mail]>]

I'm actually not sure that is how we meant it and the titles/headings should
be changed.

Perhaps that is a question to the group.

Should there be a separate service name template?
Or do we keep them together in one?

--Michelle


On 5/11/11 2:08 AM, "Magnus Westerlund" <[e-mail]>
wrote:

> On 2011-05-04 18:24, Pearl Liang wrote:
> Hello All,
> 
> Since the
> I-D.ietf-tsvwg-iana-ports has been approved, we are also in the
> process
> modifying the template forms.  The existing template forms are
> available
> at:
> 
> Port Number Application:
> http://www.iana.org/cgi-bin/usr-port-number.pl
> Modification Application:
> http://www.iana.org/cgi-bin/mod_portno.pl
> 
> Attached are two
> revised/drafted template forms.  In these drafted forms,
> I still include the
> extended texts.  Joe responded in a previous message
> that the text may need
> some revisions.  So,
> 
> [1] Please review the draft forms and texts
> (attached), and let me know if
> you have any questions and changes.

User
> Port template:

1. So there will be a separate "service name" request page?

> I do think it is a good idea, but just to ensure that this isn't
missing
> functionality.

2. "(Note: All information submitted to IANA will not be made
> public
without proper consent of the applicant.)"

Is this correct, to me this
> appears to be binding on the expert review
team also. I think you need to
> clarify in which regard you keep
confidentiality.

3. I think the template
> should make clear the difference between the
contact and the assignee with
> some wording?

4. "(Please check one(s) that is currently required.)"

Is
> "required" really the right word here? I know the intention is to
only have
> the requestor check the ones that they intended to use in the
short term. Can
> some better formulation be found?

Port Modification template:

5. Regarding
> comment 4 above, this template has a different formulation
for the
> protocols.

6. I do become uncertain if it is a modification request or new
> request
to add an additional protocol to a service. I think you need to make
> it
clear which to use.

7. If I want to change some of the SCTP specific info
> from the
registration template, how do I do that?


> 
> Further, we have
> additional questions regarding some registrations in the
> registries:
> 
>
> [2]
> Gorry, we currently have the following dccp ports listed in the
> registry:
> 
> discard           9/dccp   Discard SC:DISC [RFC4340]

The SC is
> present it is "DISC" but if you want it as a 32-bit integer it is

DISC = 44
> 49 53 43 which interpreted as an 32 bit integer are:

SC=741422379
> SC=x2c31352B

> 
> avt-profile-1   5004/dccp  RTP media data [RFC 3551][RFC
> 5762]
> avt-profile-2   5005/dccp  RTP control protocol [RFC 3551][RFC 5762]
>
> 

The following service codes are registered with RTP usage:
   o  SC:RTPA
> (equivalently SC=1381257281 or SC=x52545041): an RTP
      session conveying
> audio data (and OPTIONAL multiplexed RTCP)

   o  SC:RTPV (equivalently
> SC=1381257302 or SC=x52545056): an RTP
      session conveying video data (and
> OPTIONAL multiplexed RTCP)

   o  SC:RTPT (equivalently SC=1381257300 or
> SC=x52545054): an RTP
      session conveying text media (and OPTIONAL
> multiplexed RTCP)

   o  SC:RTPO (equivalently SC=1381257295 or SC=x5254504f):
> an RTP
      session conveying any other type of media (and OPTIONAL

> multiplexed RTCP)

   o  SC:RTCP (equivalently SC=1381253968 or SC=x52544350):
> an RTCP
      connection, separate from the corresponding RTP




> syslog-tls
> 6514/dccp  syslog over DTLS [RFC6012]

1398361159    SYLG    Syslog Protocol
> [RFC6012]



> 
> Can you please supply us with the service codes for
> those?

So I am not gorry, but they where present in the documents
> referenced.


> 
> [3]
> Is it possible for DCCP Service codes to be modified?
> Or once they are
> assigned they stay there forever?

I don't think they can
> be modified in the context of a service-name and
server port.

One thing that
> can happen is that one can request to add additional
service codes to a
> service name and a port combination.

If that is a modification of an existing
> service-name + combination or a
new request do needs to be discussed. But
> requiring it to be a new
request might be a good idea.

> 
>  
> [4]
> Should
> we include a new field for 'port number requested (optional)' in
> the
> application form?
> This way, we are not fishing through the application form
> for if they
> requested a particular port number.
> We could also add a check
> for ³no number preference².

Yes, I think that is a good idea.


> 
> [5] 
>
> Currently in the registry we have temporary assignments.  We would like to
>
> suggest the following action:
> Send the registrant an email to ask if they
> are still using the port number
> If yes, have them complete the registration
> form so that it can be
> permanently assigned
> If no, remove the port
> assignment
> If we are unable to reach them, remove the port assignment (after
> 3
> attempts)
> 
> Please let us know if you agree to this process.
> 

I
> think everything but the removal is okay. The removal is likely ok but
maybe
> should be put in the port numbers comment. The alternative is to
reserve the
> port number for now with a note that it was temporarily
assigned.

> [6]
> In
> one of our previous messages we asked the following and Joe responded:
> 
>>
> 9. What was ever decided regarding the few duplicate names in the
>>
> current ports registry? Are we doing anything with those?
> 
> [Joe] You mean
> alternates, such as "www" and "http"?
> 
> [Joe] I thought we were declaring
> one of those the primary, and listing
> the 
> others in some secondary place
> as deprecated but equivalent.
> 
> I think with http and www they are
> considered alias, however we still need
> to be instructed on what to do for
> the registry.
> 
> We also have the following case:
> 
> msp
> 18/tcp    Message Send Protocol
> msp              18/udp    Message Send
> Protocol
> #                          Rina Nethaniel <---none--->
> 
> and
>
> 
> msp        2438/tcp   MSP
> msp        2438/udp   MSP
> #
> Evan Caves <evan&acc.com>
> 
> What do we do with this?

I don't think there
> exist any good way of resolving this. I think
assigning them each an
> alternative unique name and leave in a comment
about the original not being
> unique and should not be used in lookup
usages.

Cheers

Magnus
> Westerlund

------------------------------------------------------------------
> ----
Multimedia Technologies, Ericsson Research
> EAB/TVM
----------------------------------------------------------------------
> 
Ericsson AB                | Phone  [phone]
Färögatan 6
> | Mobile [phone]
SE-164 80 Stockholm, Sweden| mailto:
> [e-mail]
-----------------------------------------------
> -----------------------

_______________________________________________
Port-
> srv-reg mailing 
> list
[e-mail]
https://www.ietf.org/mailman/listinfo/port-srv-reg