I've never thought that the IETF was OBLIGATED to "hide" old I-Ds; that
seems a rather far-fetched interpretation of anything in RFC 2026.
However, I think there is a real practical problem in making the old i-d's
be too readily available. I frequently get messages asking me question
I see this exercise has already reached the point of absurdity.
How can it possibly be worth anyone's time to look at each telnet option and
determine whether it is deployed? What possible purpose could be achieved
by changing the standards status of some telnet option? Is there some
c
> This is a simple way to simply do what we said we were going to do.
The worries about this whole anti-cruft business have always been (a) the
likelihood that it would do more harm than good, and (b) the likelihood that
it would waste enormous amounts of time on issues of no importance.
Eliot> Even if someone *has* implemented the telnet TACACS user option,
Eliot> would a user really want to use it?
Eric> I don't know. Do you?
Eliot> Yes, I do. Many of us do. And that's the point.
I'm sure you think you know, but I don't know that you know, which means
that a l
> the normal process for AD replacement involved choosing which of the
> people who had worked with the AD for a long time could do the job this
> time,
In American vernacular, this procedure is known as "cronyism".
Generally, one doesn't expect to see this advocated in a public foru
I find this whole discussion to be nothing but an attempt by some to push
their personal political views and preferences down the throats of everyone
else.
I don't think there should be any political preconditions on the IETF venue.
If we are going to start requiring that the host count
> There is no objective way to identify 'primary contributors' other than by
> assuming the regular attendees are also contributors.
This is simply silly. It's not much of a secret, in any WG, who does the
work and who comes to listen.
> We've tried looking at how many local first-time
> The random selection process coupled with the relatively small number
> of volunteers is an interesting factor in all of this
Nomcom is a group of people randomly selected from among a set of folks
whose only qualifications are that they want to be on nomcom and they like
traveling to m
I oppose this experiment.
A better experiment would be to eliminate the Friday morning sessions.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action.
If the individual submission is approved as an Experimental RFC, does that
mean that the IETF will adopt the proposed "experiment"? If so, I don't
think this draft should be approved.
> that text is not derogatory, but a simply statement of fact.
Sorry, but however you may try to talk your way out of it, a statement like
"that technology may be unstable" is derogatory.
> Until and unless the definitions of maturity levels are changed, that text
> is not derogatory, but a
The focus on document relationships rather than on simplifying the standards
track is what (well, is one of the things) that sent newtrk off into the
weeds.
Frankly, I don't care if someone on a desert island cannot figure out from
the RFCs alone how to implement some protocol. I just do
On the issue of whether we have a de facto one-step process, the real
question is not whether subsequent steps are ever invoked, but whether the
subsequent steps actually have any practical impact on the Internet. One
can certainly point to a handful of cases where the subsequent s
This document has a reasonable goal, but the implementation is objectionable.
The reasonable goal (from the introduction):
This document replaces the "hold on normative reference" rule with a
"note downward normative reference and move on" approach for
normative references to standar
Eric Gray> The discussion is essentially inane
I think this is an excellent observation. It suggests to me though that
perhaps the best way to get more funding for the IETF is to impose a
surcharge on inane messages to the ietf mailing list. The surcharge can be
based on the degree
As a personal political view, I happen to be opposed to the notion of
software patents. But I still think that the document in question should
be published as Experimental:
- It's quite plain that this political view has never been adopted by IETF
consensus. (I also think it plain
Aaron> I can easily imagine this is so, although, as I say above, I have no
Aaron> facts to back this up.
Wouldn't it be nice if people based their feedback on facts, rather than on
what they imagine! Well, at least you're honest about it ;-)
Aaron> If sub-ip represents technologies that d
Joe> Many of these discussions (layer 2 VPNs, in particular) would be better
Joe> served by occuring within the context of their original host
Joe> organization (i.e., IEEE for ethernet over IP), since it was those
Joe> organizations that defined those LANs, and they who would bes
> The workings of special interest groups can and often do have a
> significant effect on the general population, but nobody can afford the
> time and energy it takes to keep track of every special interest group
> that might affect him.
Often it seems as though the WGs ref
I might as well chime in on the actual question that was asked.
I guess I disagree with the majority of folks working in the sub-IP area. I
never thought it made any sense to move all those working groups out of
their original areas into a "sub-IP" area, and I never understood the
"
Lars> An example is PPVPN, which is chartered to work on specification of
Lars> requirements, with new protocol work being explicitly out-of-scope.
Lars> However, some current PPVPN IDs (and several more targetted at it)
Lars> read more like solution documents
>From the PPVPN charter:
Keith> In my experience, IESG has tremendous breadth - considerably
Keith> exceeding that of any single WG.
You must be joking. Or perhaps you just mean that you tend to agree with
the IESG's program of trying to preserve the academic, ivory tower vision of
the Internet against th
Steve> I can't get upset about Microsoft declining to ship poorly-tested
Steve> code. Given how many security holes are due to buggy, poorly-tested
Steve> programs, I applaud anyone who takes that seriously.
Well, suppose they were to ship IPv6 without IPsec, on the grounds that they
didn'
People need to understand that the purpose of the Pseudowire stuff (PWE3) is
to enable service providers to offer existing services over IP networks, so
that they can convert their backbones to IP without first requiring that all
their customers change their access equipment. Producing the
Harald> It might have something to do with the fact that the WG has not
Harald> requested that the IESG process these drafts if the WG has not
Harald> come to consensus on asking for the drafts to be published, I'm
Harald> afraid the IESG cannot do anything.
I consider this answe
Harald> did any of the technologies change because of issues that were
Harald> discovered in the discussions that were needed to clarify the
Harald> requirements and framework?
No.
Harald> If no - why did it take any time at all to produce them?
Not sure what you mean, it always
Eric> Not sure what you mean, it always takes time to produce a document,
Eric> even if the document is just a "rock fetch".
Harald> sorry; "rock fetch" is beyond my scope of American idiom.
"Rock fetch": when the "boss" sends the workers out on useless but
time-consuming tasks.
> "The purpose of the IETF is to create high quality, relevant, and timely
> standards for the Internet."
> It is important that this is "For the Internet," and does not include
> everything that happens to use IP. IP is being used in a myriad of
> real-world applications, such as controlli
> That is wrong or at least a gross overstatement.
If that's what you think, I invite you to make a list of all the
IETF-standardized protocols and explain how they are all (or even more than
50% of them) needed to make the Internet work.
> There have been many things that the IETF
> - "For the Internet" - only the stuff that is directly involved in making
> the Internet work is included in the IETF's scope.
In other words, routing, DNS, and Internet operations/management. Adopting
this as the IETF's mission would be a very radical change indeed! While
this particu
> Sheesh!--next you'll be telling us that you never heard the phrase
> "out of scope" before last week.
Sure I have. There's hardly a piece of work done by the IETF that someone
hasn't claimed to be out of scope. It's just that the phrase is not used
consistently. If we look at the his
> The gist of this comment is that someone developing a network
> application protocol ought to somehow get a blessing from the IETF.
> Reality check. Who got the IETF approval to deploy ICQ, Kazaa, or for
> that matter HTTP?
The fact that someone did something without the IETF's approval d
Pete> Does this particular entry mean is being
Pete> held for normative reference to the I-Ds listed below it, or that all
Pete> those I-Ds are being held for normative references?
The meaning of that queue entry is that the first document mentioned is
being delayed because of normativ
Fred> the most common hold-up that I see is a wait for normative
Fred> references. That held the MPLS documents up for a year.
This is not exactly true. In a number of cases, the documents were
explicitly crafted to have only non-normative references to internet-drafts,
but
So, here are the choices:
1. Save thousands of people from having to deal with multiple spams per day,
at the cost of presenting a minor inconvenience to a few, or
2. Require thousands of people to receive and deal with spam (or to learn
all about mail filtering), in order to avoid inc
Christian> I would much rather receive and delete another annoying
Christian> proposition to get rich quick or see lurid pictures than tolerate
Christian> any form of censorship.
As has been pointed out, the non-member messages can be moderated. It takes
about one second to look a
Maurizio> but this means
Maurizio> - that there is a person who has the right to decide whether the
Maurizio> message is spam or not
Maurizio> - that this person is willing to bear the burden for the sake of the
Maurizio> whole community.
Maurizio> I happen to do this for some lists, but it
Brian> NAT has simply pushed us back to the pre-1978 situation.
On the contrary, NAT has allowed us to maintain global connectivity without
requiring every system to have a globally unique address. NAT is what has
prevented us from returning to the pre-1978 situation.
That's not to say
Fred> I see a longish thread about the fact that some cable companies
Fred> apparently are desperate to charge per IP address (something one can
Fred> only do if IP addresses are in fact a scarce resource)
I think you miss the point here. The cable companies want to charge per
comp
Sure, in theory one could add zillions of new globally routable addresses
without increasing the size of the routing tables in the default-free zone
at all.
The skepticism is about whether there is (or even could be) a realistic plan
to make this happen.
Eric> NAT is what has prevented us from returning to the pre-1978 situation.
Keith> this is true only if you believe that [blah blah blah]
The situation today with NAT is that hosts in separate realms can only
communicate in 99% of the desired applications, though perhaps this falls to
I don't think folks have appreciated how truly insidious Russ' document is.
First, he proposes to eliminate a set of processes that are frequently used
to portray the IETF in a negative light:
- The use of the label "Standard" for the never-used third level of
standardization
- The never-used
With regard to this draft, I need to reiterate a comment I made during WG
last call, as I think there is a procedural issue that needs to be brought
to the IESG's attention.
The draft has a normative reference to RFC 3472 "Generalized Multi-Protocol
Label Switching (GMPLS) Signaling Constraint-ba
> Minor issues:
> - Section 3, 2nd para, second sentence is:
>
> "A Type 4 S-PMSI Join may be used to assign a customer
>IPv6 (C-S,C-G) flow to a P-tunnel that is created by
>PIM/IPv4. "
> I'm curious how else might a Type 4 S-PMSI be used? This sentence
> makes it seem unclear as to wh
James> perhaps this needs to be stated (that the Type 4 is created by this
James> doc for your purpose)?
I think the doc already makes this clear, maybe I'm not sure what you are
asking.
James> You can probably imagine how many SIP and RSVP protocol extensions
James> there are (70+ and about 20
> RDP is still in use
> was the initial transport used for gateway control (such as SGCP) until
> SCTP was developed.
> Many commercial gateways still support these older pre-standard (to
> MEGACO) control protocols. Some older devices still provisioned in the
> network only support the older p
Phillip> But I rather suspect that the reason that this is happening is that
Phillip> people know full well that there is a process and choose to ignore
Phillip> it because they either can't be bothered to put up with the hassle
Phillip> or don't think that the application will be accepted.
Lars>
This document really wants to be a BCP that makes deployment and strategy
recommendations. But for some reason it has been disguised as a standards
track document (i.e., as a protocol specification), and the result is that
RFC 2119 language is being used in a very peculiar way. I think this is
wh
Adopting this document as a BCP would be a serious mistake, and I hope it
will be strongly opposed.
There is absolutely no evidence that following the dictates of this document
will improve the quality of the IETF's work, and we certainly know it won't
improve the timeliness. There is no evid
> This does not mean we have to simply accept what they (OPS) say. But it
> does mean we should give it a fair review, looking at the details,
> rather than objecting on principle.
This is absolute nonsense. Most of the people actually doing work in the
various areas do not have the time,
Looking through your summary of the LC comments, it appears that there is
considerable sentiment to publish this document as Informational rather than
as a BCP. Yet the new revision still says "Intended Status: BCP".
> [dbh: this document went to great lengths to say that it was NOT
> prescribi
Lars> since you asked: I have absolutely no problems with xml2rfc.
I find that xml2rfc takes too much control over the boilerplate and the
references to be a really useful tool. I dropped it after one attempt.
However, many of my colleagues use it, and as a result I've gotten many
> huge number of mobile devices that handle HTML effortlessly and IETF
> legacy ASCII not at all
HTML is a good presentation format, but as an archival format it seems to
leave a lot to be desired, as the included links always seem to go stale.
Also, I don't think that the notions
Thank you for your review. I will try to address your technical comments.
Some of your comments are not really technical objections, but criticisms of
the way the document is constructed, or of the scope of the document, or of
the approach adopted by the WG. As the construction of the document i
> So, I recommend an errata to RFC 2119: "These words MUST NOT appear in a
> document in lower case."
I'm glad you said "I recommend" instead of "I have recommended", as the
latter would violate the recommended (oh dear) rule.
This RECOMMENDED rule would also imply that documents can no longer b
I think the procedures proposed in this draft could be simplified a bit if
we'd just focus on the actual issue, viz., that the implementation and
deployment of a new specification is completely decoupled from the progress
of that specification through the standards process. Once any significant
de
56 matches
Mail list logo
