Re: [tcpm] IANA TCP options registry ...

[Alfred Hönes <[e-mail]>]

William Allen Simpson wrote:

> On 4/1/10 4:36 AM, Alexander Zimmermann wrote:
>>> Section 10 is pretty clear, in that RFC5690 is for limited
>>> experimentation only at this time and hence no separate option
>>> numbers will be assigned.  Experimenters are supposed to use the
>>  normal TCP option numbers set aside for general experimentation
>>> (253/254) when playing with this proposal:
>>
>> this could be funny in Linux. You request ACKcc as TCP sender (option 253)
>> and get Mr. Simpson's TCP Cookie Transactions back ;-)
>>
> Haven't seen that (RFC5690) so far, but there's somebody else using 253 and
> another somebody using 254 in deployed code!  There are earlier messages on
> this list about the culprits.
>
> Last year's Linux code used the experimental numbers and followed the usual
> procedures (you have to explicitly turn it on with a sysctl or sockopt),
> but the conflicts were quickly obvious.  Don't turn it on outside your lab.

That's it.
The rules about these 'experimental' code points have been set out
very clearly in RFC 4727, and "deployed code" or even "commercial"
implementations are not compatible with these.


> The only reason that I've bothered putting up the internet-draft is to get
> official IANA assignments.  I'd sent in the reservation back in November,
> but IANA refused to send it to IESG for approval without an internet-draft.
> Unfortunately, IESG has been *terribly* slow to act.

Well, I fear in *this* case neither IANA nor the IESG should be blamed:

The IANA registry at
  <http://www.IANA.ORG/assignments/tcp-parameters/>
clearly points out:

|  Registry Name: TCP Option Kind Numbers
|  Reference: [RFC2780]
|  Registration Procedures: IESG Approval or Standards Action

RFC 5226 (lower half of page 11) explains the "IESG Approval" policy
as exceptional and gives two indications for when it should be applied:
   - urgency (used recently to get early code point assignments for TLS
     after a new class of MitM attacks had been discovered and work to
     counter these had started), and
   - strong WG consensus (for a non- Standards Track proposal).
RFC 5226 also states there:
   "IESG Approval is not intended to circumvent the public review
    processes implied by other policies that could have been employed
    for a particular assignment."

In this case, RFC 2780 has established approval of an I-D as a
Standards Track RFC as the "normal" requirement ("Standards Action").

Obviously both exceptions quoted above are not proper matches for your
case, and so I still do not see the procedural rule on which you have
based your expectation of exceptional treatment.
Or did I miss something?

Sorry: In this case, avoidance of IETF WGs strikes back.


> Unlike certain commercial interests, I'm trying to avoid conflicts.
> But next time, I'll not bother.  IETF officialdom has become too
> ossified.

I do not want to argue on the final point here, but it looks like in
this case the IETF (an the IESG) is simply eating their own doggy-food,
and as shown above, this has nothing to do with ossification of the
institutions tasked with the execution of the procedures set by the
IETF.  If the taste of the doggy-food is perceived as being bad, we
should better try to modify it (i.e. the rule in RFC 2780 -- see my
previous posting on this thread), and not merely complain about it.

It is generally seen that for major protocols where experiments
in closed lab environments do not suffice to gain siginificant
experience before standardization, some rules set by the IETF
for IANA policy are too restrictive.  The wave of RFCs and drafts
seen during the last couple of years that aim at making additions
to IETF protocols easier is a clear indication that in some Areas
of the IETF the value of experiments and running code is gaining
back momentum.  For TCP and TLS, that's not the case, for instance.
It's ours to request and drive change for the rules if they hurt.


Kind regards,
  Alfred.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: [phone], Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [e-mail]                     |
+------------------------+--------------------------------------------+