DCCP protocol discussions
 help / color / mirror / Atom feed
From: Gerrit Renker <gerrit@erg.abdn.ac.uk>
To: dccp@vger.kernel.org
Subject: Re: [RFC][PATCH 2/2]: Promote CCID2 as default CCID
Date: Tue, 07 Aug 2007 11:21:47 +0000	[thread overview]
Message-ID: <200708071221.48077@strip-the-willow> (raw)
In-Reply-To: <200708021546.30471@strip-the-willow>

|  >     Providing CCID2 as minimum-required CCID (like Reno/Cubic in TCP) seems reasonable.
|  
|  I don't think it is required. The current Kconfig setup builds it by
|  default if you enable DCCP/
Yes that is true, but only in form of a default value; due to 
 config IP_DCCP_CCID2
        # ...
        def_tristate IP_DCCP     < ---

My point of view is that only experienced people should disable CCID2; firstly due to the
default assumptions (without further ado and configuration, DCCP will try to load CCID2 as
its assigned default CCID), and further due to the suggestion in 4340 as a default: for an
unexperienced user, using CCID3 can have a bit of a learning curve.

  
|  I think this is worthwhile and should go ahead still. Better
|  documentation is always good. Couple of minor nits with this which
|  I've got below.
Thanks a lot - I will address this and re-post.

|  > +DCCP is a proposed IETF standard, and the homepage for DCCP as a protocol is at:
|  >         http://www.read.cs.ucla.edu/dccp/
|  
|  Home page is really
|  http://www.ietf.org/html.charters/dccp-charter.html now and isn't it a
|  standard now rather than proposed standard?
|  >
Hm, don't think so - if you look at the three levels of RFC 2026:

 * Proposed standard requires some maturity of specification, but:
    "Implementors should treat Proposed Standards as immature specifications. It is 
     desirable to implement them in order to gain experience and to validate, test, 
     and clarify the specification. However, since the content of Proposed Standards
     may be changed if problems are found or better solutions are identified, deploying
     implementations of such standards into a disruption-sensitive environment is not 
     recommended." (sec. 4.1.1)

 *  Draft Standard: "A specification from which at least two independent and interoperable
                     implementations from different code bases have been developed [...]"
    We've got enough work already with one alone ... :)

 * Internet Standard: "A specification for which significant implementation and successful
                       operational experience has been obtained [...]"


      reply	other threads:[~2007-08-07 11:21 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-08-02 14:46 [RFC][PATCH 2/2]: Promote CCID2 as default CCID Gerrit Renker
2007-08-07 11:21 ` Gerrit Renker [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200708071221.48077@strip-the-willow \
    --to=gerrit@erg.abdn.ac.uk \
    --cc=dccp@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox