Subject: Re: [apps-discuss] Fwd: I-D Action:draft-hartmann-default-port-for-irc-via-tls-ssl-01.txt

From: SM <[email-masked]>
Date: Sat, 02 Oct 2010 00:37:23 -0700

At 15:21 27-09-10, Peter Saint-Andre wrote:
>I'm not sure if IRC counts as Apps or RAI these days, but I figured this
>I-D might be of interest here...

Send it to RAI. :-)

The Abstract section should be the first section.

If the document is to establish a "best current practice", it should 
be published on the Standards Track instead of Informational.  If it 
is only about registering a port, it does not have to be on that 
track.  This draft may attract the attention of the "security" 
community and the discussions might go on a tangent.

How does this document update RFC 1459, RFC 2810, RFC 2811, RFC 2812 
and RFC 2813?

In Section 1:

   "Although system port assignments for both plain text (TCP port 194)
    and TLS/SSL encrypted (TCP port 994) IRC traffic exist [IANALIST], it
    is common practice amongst IRC networks not to use them for reasons
    of convenience and general availability on systems where no root
    access is granted or desired."

draft-ietf-tsvwg-iana-ports-06 provides some information about the 
assignments of port numbers in the past.  As the port number space is 
a limited resource, how can the formal assignments of one more ports 
be justified?

   "This is covered by the IRCU assignment of TCP/UDP ports 6665-6669."

Although it is common practice to use these ports, they are current 
listed as unassigned.

In Section 2:

   "This document does not directly discuss security issues, however the
    lack of a common, well established listening port for IRC via TLS/SSL
    could lead to end users being unaware of their IRC network of choice
    supporting TLS/SSL."

Please see RFC 2782.

Regards,
-sm

---

From: Richard Hartmann <[email-masked]>
Date: Sun, 3 Oct 2010 01:29:53 +0200

> Send it to RAI. :-)

OK, I will :)

> The Abstract section should be the first section.

The docs state that the abstract can be put before or after the leading
boilerplate, but must be before the TOC. I am fine with either position.

> If the document is to establish a "best current practice", it should be
> published on the Standards Track instead of Informational.  If it is only
> about registering a port, it does not have to be on that track.  This draft
> may attract the attention of the "security" community and the discussions
> might go on a tangent.

I am still unsure about this. Initally, I was told that Informational RFCs are
a lot easier for both author and the RFC editors and that the could be
submitted directly. It seems this has changed recently as the RFC editors
asked me to start with an I-D, first.
As I am going the I-D route anyway, it probably makes sense to switch
away from Informational.

> How does this document update RFC 1459, RFC 2810, RFC 2811, RFC 2812 and RFC
> 2813?

Those are the RFCs referring to IRC. I thought it would be better to err
on the save side & include them.

> assignments of port numbers in the past.  As the port number space is a
> limited resource, how can the formal assignments of one more ports be
> justified?

According to the IANA [1]:

"The IESG believes that IANA may allocate an additional port in the 'user
port' range to protocols whose current port allocation requires access to a
privileged port. This allocation should not be automatic, but may occur
upon application by an interested party whose application would otherwise
fit IANA's policies."

> Although it is common practice to use these ports, they are current listed
> as unassigned.

No, see [2].

> Please see RFC 2782.

Realistically speaking, this will not be implemented in IRC. Not ideal,
granted. But realistic.

Thanks for your feedback,
Richard

[1] http://www.iana.org/cgi-bin/usr-port-number.pl
[2] http://www.iana.org/assignments/port-numbers

---

From: SM <[email-masked]>
Date: Sat, 02 Oct 2010 22:46:29 -0700

Hi Richard,
>OK, I will :)

I see that you got better feedback from RAI.

>As I am going the I-D route anyway, it probably makes sense to switch

Documents always start as Internet-Drafts whether they are intended 
as Informational or Standards Track in the IETF Stream or 
Informational in the Independent Submissions Stream (RFC 4846).  Adam 
Roach already mentioned [1] that it  is going to be a lot of work if 
the document goes beyond the formal registration of the port.

>on the save side & include them.

The status of RFC 1459 is Experimental.  That RFC was updated by RFC 
2810, RFC 2811, RFC 2812 and RFC 2813 which were published as 
Informational RFCs.  draft-hartmann-default-port-for-irc-via-tls-ssl 
is somewhat related to Section 7.2 of RFC 2813.

>According to the IANA [1]:

See below.

>No, see [2].

I missed that.

Regards,
-sm

1. http://www.ietf.org/mail-archive/web/rai/current/msg00943.html

---

From: Richard Hartmann <[email-masked]>
Date: Wed, 6 Oct 2010 14:39:46 +0200

> I see that you got better feedback from RAI.

Indeed. I could not answer yet, but I am about to after I finish
this mail.

> Documents always start as Internet-Drafts whether they are intended as
> Informational or Standards Track in the IETF Stream or Informational in the
> Independent Submissions Stream (RFC 4846).  Adam Roach already mentioned [1]
> that it  is going to be a lot of work if the document goes beyond the formal
> registration of the port.

I still not sure how this could be that much work seeing as the I-D is limited
to a small subset of the issues. More on that in the other thread, though.

> The status of RFC 1459 is Experimental.  That RFC was updated by RFC 2810,
> RFC 2811, RFC 2812 and RFC 2813 which were published as Informational RFCs.
>  draft-hartmann-default-port-for-irc-via-tls-ssl is somewhat related to
> Section 7.2 of RFC 2813.

Afaik, RFC 1459 has been updated but not obsoleted by the other RFCs so I still
think it should be included unless transitive Updates: are the norm.

> See below.

As in, you missed that as well?

Thanks,
Richard