|
Re: RFC 4612 - historic status
2006-08-14 05:24:42
Dear Todd,
what is specified/you ask is logic. But the pluses of the IETF also
come from not being that formal. Some kind of fuzzy logic. I thought
for a while it could be corrected by the users from inside (hence my
involvement). I hoped we would have less difficulties like this one,
less ethical problems, less affinity groups and more practical
diversity, and not to wait for a mid-term judgment by the market.
From my experience - in particular with languages and OPES - I think
now that the usership contribution should be organised differently.
We would need one or several users systems groups, building
_complete_ system logics (distributed/used as such), shopping their
specifications among the different SSDOs, interacting with all of
them and the IETF, and bringing some crosspolinization. This is what
W3C, this is what ICANN, this is what UNICODE, etc. partly do. But
none of them targets a complete network operating system and
environment, bringing the need of a complete model of reference. I
think you could be among those investigating that.
I hoped the IAB mailing list on a future architecture could help
this. This is why I said I was only interested by an architecture by
usage (as we start seeing the Multilingual Internet implemented).
Because it permits some kind of fuzzy architecture, accepting
different visions, and supporting simultaneous evolutions. It went so
far as shortly discussing the need of a/several network OS(es). But
the debate died.
jfc
On 05:25 14/08/2006, todd glassey said:
Mr. Jones - welcome to the smoke screen. What you are finding is that this
IETF does not have most of the formal infrastructure that its documents
allude to. It has no formal method of creating Informational Filings and in
all instances passes them off as Historic as though only genesis that
happens within the IETF counts in this world.
Understand some of my frustration at trying to get other key entities to
adopt processes with the IETF when they have no
1) process for inducting information from external sources that is
published for reference and not for development or respect for copyrights of
contributors, or those filing for informational purposes where there is no
copyright conveyance beyond joint-publication rights.
2) process for accepting formal notice of anything relative to this
thing called erroneously a Request For Comments (which based on IETF
processes could be called an Internal Technology Vetting Document since it
really isn't a 'request for anything' but rather a proclamation for people
to base other things on.
3) method at the organizational level of cross-collaboration on
anything with anyone... there have been some unusual instances in various
WG's where cross-collaboration between other externals and the WG occurred
on a project level; but at the organizational and more importantly the
brand-recognition level - this IETF has nothing really implemented to
address these needs.
Ah well...
todd glassey
----- Original Message -----
From: "Paul E. Jones" <paulej(_at_)packetizer(_dot_)com>
To: <dcrocker(_at_)bbiw(_dot_)net>; "'Brian E Carpenter'"
<brc(_at_)zurich(_dot_)ibm(_dot_)com>
Cc: <ietf(_at_)ietf(_dot_)org>
Sent: Sunday, August 13, 2006 8:09 PM
Subject: RE: RFC 4612 - historic status
> Dave,
>
> This is the second document this year that I published through the IETF
that
> was classified as "historic". The was RFC 4351.
>
> In both cases, I was working in the ITU on fax and modems issues and with
> people looking for a way to efficiently transport modulated signals
between
> two PSTN gateways over IP. For both cases, consideration was given to:
> 1) We needed a way to provide security
> 2) We were working with a narrow scope (GW to GW)
> 3) We wanted something that would not be resource intensive
> 4) We wanted to minimize signaling requirements
>
> Since, for all intents and purposes, "fax" signaling or "text" signaling
> between two PSTN gateways is nothing more than an alternative
representation
> of "audio", it was decided that we would define a means of switch media
> types on the fly. The reasoning seems good, engineers liked it, and the
> standards were approved (ITU-T Rec. T.38 and ITU-T Rec. V.151).
>
> We were able to meet all of the above (and other) requirements using this
> method. For the folks I worked with, it was really no different than
> sending RFC 2833 to represent DTMF. (There are known differences in the
> media characteristics, such as a change in bandwidth usage, transmission
> rates, etc. However, all of those aspects were well understood and not
> really subject matter for these RFCs, anyway.)
>
> We could have elected to not publish RFC 4351 and simply include it in
ITU-T
> V.151. Now, we have an "historic" document in the IETF referenced by a
> brand new international standard published by the ITU. Now, that is
silly.
> To some extent, I regret having presented the text to the IETF in the
first
> place.
>
> In the case of the audio/t38 document (RFC 4612), this was written only
> because, if I read RFC 4288 correctly, such a document is needed to
register
> a MIME type in the IETF tree.
>
> In the case of MIME, we could have used a different tree (e.g.,
> audio/itu.t38). However, as far as I know, there is no such tree.
> Secondly, while it might be easy to get such a tree, there are various SDP
> parameters and other such things the ITU has defined in recommendation
> (e.g., V.150) for which there are no "trees". I like symmetry.
>
> For those SDP parameters to which I refer (ITU-T Rec. V.150 being one such
> standard containing unregistered parameters), the IETF has apparently
> refused to publish an RFC for at least one SDP parameter (gpmd). This
> leaves the industry in a very awkward situation, since we have SDP
> parameters appearing in ITU standards that are not registered with IANA.
>
> The short of it is that the cooperative spirit and the process are broken
to
> some degree. I don't have my favorite standards body, though I have
worked
> in many of them like a good number of the other folks in the IETF. So,
> don't assume I'm arguing from one side or another. I'm just an engineer
> caught in the middle of standards-making organizations trying to get my
job
> done.
>
> I wonder how customers might react to seeing new gateway hardware produced
> utilizing "historic" RFCs. What does that mean?
>
> Paul
>
> > -----Original Message-----
> > From: Dave Crocker [mailto:dhc2(_at_)dcrocker(_dot_)net]
> > Sent: Thursday, August 10, 2006 2:13 PM
> > To: Brian E Carpenter
> > Cc: ietf(_at_)ietf(_dot_)org
> > Subject: Re: RFC 4612 - historic status
> >
> >
> >
> > Brian E Carpenter wrote:
> > >> Historically, "documenting for reference" produces an Informational
> > status,
> > >> rather than Historic.
> > >
> > > Yes, and the idea was to make a stronger statement than "for
reference".
> > > iirc, we considered briefly approving it for Informational and then
> > > immediately reclassifying it as Historic. But that seemed silly.
> >
> >
> > If the IETF wanted to "make a statement" why not merely add text that
> > makes the
> > desired statement?
> >
> > Again, this has been the usual approach. Why change from that?
> >
> > Going to Informational and then Historic would, indeed, be silly. It
> > confuses
> > the semantics of Informational, since it implies that Informational has
> > some
> > sort of standards status.
> >
> > The model that has the IETF focus heavily on matters of "precedence",
> > particularly with respect to specifications that are not standards
track,
> > seems
> > questionable, at best. It means that rather than relying on questions
of
> > technical efficacy, scaling, and the like, the IESG is instead worrying
> > about
> > future, hypothetical, unstated human abuses.
> >
> > At the least:
> > > concern that the format not become a precedent
> > > for future media types
> >
> > should produce explicit text added to the document, so that readers can
> > understand whatever problems there are with this approach.
> >
> > d/
> > --
> >
> > Dave Crocker
> > Brandenburg InternetWorking
> > bbiw.net
> >
> > _______________________________________________
> > Ietf mailing list
> > Ietf(_at_)ietf(_dot_)org
> > https://www1.ietf.org/mailman/listinfo/ietf
> >
>
>
>
>
> _______________________________________________
> Ietf mailing list
> Ietf(_at_)ietf(_dot_)org
> https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf
|
|