Subject: RE: Impending publication: draft-iab-considerations-02.txt

From: Adam Roach <[email-masked]>
Date: Fri, 6 Sep 2002 10:11:01 -0500

I wanted to make a quick comment about some text in section
12.1 of the draft cited below.

  "In addition, there are extensions of SIP which
   are under consideration in these [external] standardization bodies
   that are not appropriate material for IETF, because they are not
   generally applicable but only relate to the particular application
   of SIP being developed by the standardization bodies. An example
   is particular interactions with accounting and billing for mobile
   telephony."

I believe this is a slight misrepresentation of the policy that has
been communicated by the transport area directors to the working group
and other standards bodies. In particular, the document cited as
[BMMWRO02] makes some particularly strong statements that all deployed
SIP extensions are to involve the IETF in some fashion. For example:
"All changes or extensions to SIP must first exist as SIP Working Group
documents," and "With the exception of "P-" headers described in Section
4.1, all SIP extensions must be standards track and must be developed
in the IETF."

On the topic of "P-" headers, however, there is still guidance that
such extensions require, at a minimum, publication as an RFC:

  "[A]ny P-header used outside of a very restricted research or teaching
   environment (such as a student lab on implementing extensions) MUST
   meet those requirements and MUST be documented in an RFC and be IANA
   registered."

While the text that appears in section 12.1 of draft-iab-considerations-02
does not directly contradict any of these statements, it does give the
impression that such external standards bodies are free to create SIP
extensions without any contact with the IETF. I beleive that additional
text to clarify that such extensions still require IETF involvement would
clear matters up sufficiently. I propose adding a sentance to the final
paragraph of section 12.1 along the lines of: "In the interest of
preserving the integrity of the protocol, however, such externally
developed extensions are still reviewed and published by the IETF."

/a

(Adam Roach, dynamicsoft)

-----Original Message-----
From: Leslie Daigle [mailto:[email-masked]]
Sent: Thursday, September 05, 2002 17:34
Subject: Impending publication: draft-iab-considerations-02.txt

The IAB is ready to ask the IESG to publish

            General Architectural and Policy Considerations
                 draft-iab-considerations-02.txt

as an Informational RFC.  This document is part survey of issues,
and part advice for IETF protocol development.  The IAB would
like to ensure that the IETF community has had an opportunity to
read it and comment before its publication.

The IAB solicits comments by September 20, 2002.  Please send 
comments to the IAB ([email-masked]), care of the document editor 
([email-masked]), or to [email-masked].  The document can be 
found at 

http://www.ietf.org/internet-drafts/draft-iab-considerations-02.txt

Leslie Daigle
For the IAB

---

From: Robert Elz <[email-masked]>
Date: Fri, 06 Sep 2002 23:39:11 +0700

Date:        Fri, 6 Sep 2002 10:11:01 -0500 
    From:        Adam Roach <[email-masked]>
    Message-ID:  <[email-masked]>

  | On the topic of "P-" headers, however, there is still guidance that
  | such extensions require, at a minimum, publication as an RFC:
  | 
  |   "[A]ny P-header used outside of a very restricted research or teaching
  |    environment (such as a student lab on implementing extensions) MUST
  |    meet those requirements and MUST be documented in an RFC and be IANA
  |    registered."

This kind of text in any RFC (or other publication) is no more than an
attempt at extortion.   Nothing published in an RFC can possibly constrain
what anyone else does, anywhere.   Believing otherwise is ludicrous.

We can constrain our own behaviour, since that's what we control, so we
could (assuming that we believe IANA is part of "us") specify that IANA
must not register a header unless it is documented in an RFC.   But we
cannot tell people that they're not allowed to use such things.   Or more
correctly, of course we can tell them that, but without any expectation
that many of them will take us seriously.

Whether or not the IETF decides that it should adopt work done by others
(even just as much as re-publishing it for information) will be something
that should get decided on a case by case basis (or as agreed with other
bodies in appropriate circumstances), but pretending that the IETF is the
supreme lord of the universe, and everyone else must bow down to the
pronouncements in RFCs (even in cases where IETF created technology is
under discussion) is laughable.

kre

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Sun, 08 Sep 2002 18:41:22 +0200

--On 6. september 2002 23:39 +0700 Robert Elz <[email-masked]> wrote:

>   |
>   |   "[A]ny P-header used outside of a very restricted research or
> teaching   |    environment (such as a student lab on implementing
> extensions) MUST   |    meet those requirements and MUST be documented in
> an RFC and be IANA   |    registered."
>

note that a MUST in an RFC has no enforcement mechanism whatsoever.

The most that can be said is something akin to "if you do the opposite of 
what these words say, and claim to be conformant to this RFC, we will laugh 
at you".

So if you start selling out a product that sends P-THIS-IS-NOT-DOCUMENTED 
headers, and claim that it is conformant to SIP as specified by the IETF, I 
will point to this document and laugh at you.

If that's extortion, then so be it.

                    Harald

---

From: Robert Elz <[email-masked]>
Date: Tue, 10 Sep 2002 13:18:13 +0700

Date:        Sun, 08 Sep 2002 18:41:22 +0200
    From:        Harald Tveit Alvestrand <[email-masked]>
    Message-ID:  <878248073.1031510482@localhost>

  | > "[A]ny P-header used outside of a very restricted research or
  | > teaching environment (such as a student lab on implementing
  | > extensions) MUST meet those requirements and MUST be documented in
  | > an RFC and be IANA registered."

  | If that's extortion, then so be it.

Harald, you missed my point.   It wasn't the restrictions on implementors
I was meaning - that implementors shouldn't use headers except where
documented as...   is just fine, and the effects that has on conformance
and what they should claim, just as you said.

There's nothing unusual in any of that.

But read the above quote again.   What it says is  "MUST meet those
requirements and" ...

That is, the IETF (according to this) cannot specify a new P-header
unless it meets the requirements in that doc (or if they do, implementors
are still not free to use it, even if it is documented in an RFC and
registered by IANA.    That is, they can't if they want to remain
conformant, of course, and often, they do.

It is extortion aimed at the IETF community that I am worried about,
and what's more, I have seen this work.   Some WG (perhaps the same one
that published an earlier doc, perhaps a different one) looks at an RFC
which says what can or cannot be done, and without further thought, rejects
a proposal, because it does not conform with some rule laid down by some
earlier doc (which most likely hadn't even considered the situation
now being proposed).

I take Adam's point that this is just an I-D, and it is, in this particular
case, to the authors of that I-D (and/or its WG) that this point should be
made (it isn't a WG I normally have anything to do with at all).

The point for the wider community is that there is *nothing* in an RFC that
can't be changed by a later RFC.  And there should not be language in any
RFC that attempts to prohibit that.   The way to avoid future possible changes
perceived as being not in the best interests of the protocol, is to explain
why they would be detrimental, not just to prohibit them (or pretend to).

Of course, when it is noticed that something is contradicting an earlier
RFC (and it always is in the cases here where it matters - if people don't
notice and just do it anyway, that's a completely different problem)
that should give rise to caution - one should ask why the restriction is
there, etc, and consider carefully before ignoring it.   But after having
done that, all WGs should be aware that they're free to change anything in
any protocol al all.   IETF Last Call will often then raise objections of
course, so the attempt might end up failing.   But if the arguments for the
change are good enough, then nothing any earlier RFC says, or claims must be
done, has any particular power to prevent the change.

kre

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Mon, 16 Sep 2002 03:57:34 +0200

--On 10. september 2002 13:18 +0700 Robert Elz <[email-masked]> wrote:

> which says what can or cannot be done, and without further thought,
> rejects a proposal, because it does not conform with some rule laid down
> by some earlier doc (which most likely hadn't even considered the
> situation now being proposed).

Robert,

thanks for clarifying - I did misunderstand your first message.
I think you have the reason why documents specify such "forward-looking 
prohibitions" described exactly, and your words also point out the right 
way to handle it.

The sipchange draft is the result of a good deal of thinking and discussing 
about the dangers of extensibility in the particular case of SIP.
There will certainly be cases in the future when someone proposes some 
action that does not fit in with that rule.

And in some cases, that action is the Right Thing to do.
But I think it is right and proper that once one encounters such a 
situation, one should take responsibility for not only steamrollering the 
nonconformant proposal through the IETF (and we have done that, too...) but 
also to read and understand the rule laid down in the past, and undertake 
the effort to *change* that rule, because it no longer fits the real world.

Blithely ignoring a conclusion because it was drawn a year ago is as 
harmful (IMHO) as blithely ignoring new ideas because they don't conform to 
the "received wisdom".

In my opinion, which is neither particularly new nor received wisdom.

                       Harald

---

From: Robert Elz <[email-masked]>
Date: Tue, 17 Sep 2002 16:54:57 +0700

Date:        Mon, 16 Sep 2002 03:57:34 +0200
    From:        Harald Tveit Alvestrand <[email-masked]>
    Message-ID:  <44304256.1032148654@localhost>

  | Blithely ignoring a conclusion because it was drawn a year ago is as 
  | harmful (IMHO) as blithely ignoring new ideas because they don't conform to 
  | the "received wisdom".

Absolutely.

The problem is that when this happens, it can be difficult, at best,
to

  | and undertake 
  | the effort to *change* that rule, because it no longer fits the real world.

Updating some earlier RFC is most likely not in the WG's charter, especially
not if the doc in question originated from some entirely different WG.

When faced with that situation, if the rule really was "that the earlier doc
had to be changed explicitly", then however good the reasons for ignoring some
earlier rule in this particular case, no-one would bother - some other
workaround (possibly with other problems) is going to be found instead.
That is, doc X says we cannot do Y, it is ultra vires for us to change X,
hence, we cannot do Y - we have to do something else instead.

Perhaps fortunately, the rule isn't like that - we have nothing in our
procedures that claims that in the case of a dispute, older RFCs win over
new ones, and lacking anything explicit that way, the rule has to be that
new ones win if there's a dispute.   After all, all of these docs are,
when eventually processed, docs issued by the same body (the IETF as a
whole), and when that happens, newer requirements/specifications implicitly
override earlier ones (especially so when the new one is quite specific,
and the old one general, which is the kind of situation here).

Because of that, WGs know that they can go ahead and specify something
that overrides some earlier rule.   (That they also sometimes do that
without realising what they're doing is another problem, a quite
different one, as I mentioned in an earlier message).

Note that we do this all the time in "normal" cases without any problems.
A doc might say that "only x y and z are valid here", then some other doc
comes along and adds "and w is valid as well, and means ...".

That kind of thing causes no problems (assuming the extension is
well designed, etc, of course - no interpretation problems I mean).

But when the first doc says "only x y and z are valid, and no others
are ever allowed to be added" (or constrains the method by which more
are added, in such a way that it pretends to limit the IETF) then some
other doc comes along and says "and w is valid as well", then there's
a problem, because according to the first doc, the 2nd one is irrelevant.
That is, there's no way anyone can conform to both.

Fortunately, the fix is easy - we simply don't publish any docs that
pretend that they specify what is permitted to be done in the future,
by the IETF, other than our procedures documents of course (essentially
our constitution, which can itself be modified, and cannot claim that it
can't be).

Regular docs can specify what is required now, and if they want, can also
specify an extension mechanism by which additions can be made.  Anything
which pretends to limit the way the IETF processes future documents should
be discarded, or the doc not published.

The restrictions don't, and can't, work anyway, putting them there just
causes problems.

But, once again, by all means have docs explain why future people might
want to act in a certain way, and before approving something which acts
differently, we probably want to take a close look at why.   But if we
do that, and are satisfied, let's not complicate matters.

Note: it is OK to require no extensions without explicit IETF action.
In the kind of case that seems to be happening here, that means that
the original community get to look at the proposed change, and object
to it, because of whatever reasons are currently leading the WG to
try and include language to limit the IETF in the future.  If a doc
were to propose something, which would run into the problems that the
restriction is trying to avoid, I'd expect someone to object (and if the
reasons were spelled out in the doc, I'd expect that, way off into the
future).   If there are objections like that, backed by good reasons,
and no satisfactory answers, then the new doc should be killed at IETF
last call time (killed or modified).   But if there are no objections
(or any that are made are answered to the community's satisfaction)
then that's all that we need, to allow the change to proceed.

kre