Note that RFC 3619 is a document published for the information of the
Internet community, via the RFC Editor, and not as part of the IETF
standards process; I don't believe that the IETF makes any requirement
on patent disclosure on such documents.
That said, it is nice that Extreme has
Note that RFC 3619 is a document published for the information of the
Internet community, via the RFC Editor, and not as part of the IETF
standards process; I don't believe that the IETF makes any requirement
on patent disclosure on such documents.
Well, any I-D that contains the required
Robert == Robert Sayre [EMAIL PROTECTED] writes:
Robert On 10/17/06, Sam Hartman [EMAIL PROTECTED] wrote:
Michael Can an appeal be rejected with merit?
Yes. I think Robert's recent appeal was rejected that way.
Robert I don't feel that way. I did wait a long time for a
Ted Hardie wrote:
For the charter discussions, I want to know whether it will
be an aim of the working group to standardize:
* a way of carrying this information
* the structure of this information (but not its content)
* a standard representation of the content, so that access to the
vendor
Dear All,
I am a Masters Student at Southern Methodist
University, Dallas TX.
I am doing a project on NAT traversal in SIP in the
IMS network. I am discussing the problems for the RTP packets while NAT
traversal. One of the solution to it is the STUN and TURN servers.
I would really
Sam Hartman wrote:
Robert == Robert Sayre [EMAIL PROTECTED] writes:
Robert On 10/17/06, Sam Hartman [EMAIL PROTECTED] wrote:
Michael Can an appeal be rejected with merit?
Yes. I think Robert's recent appeal was rejected that way.
Robert I don't feel that
Robert == Robert Sayre [EMAIL PROTECTED] writes:
Robert OK. I want to write a document that makes MTI a
Robert non-requirement for HTTP1.1-based protocols, because I
Robert believe that is the consensus in the HTTP community. How
Robert do I get that done?
You start by writing a
On Thu, 19 Oct 2006 12:29:07 -0400, Robert Sayre [EMAIL PROTECTED]
wrote:
OK. I want to write a document that makes MTI a non-requirement for
HTTP1.1-based protocols, because I believe that is the consensus in the
HTTP community. How do I get that done?
Are you trying to change general
After re-read Brian's draft, RFC 3683, RFC 3934, and the relevant
portions of RFC2418
I support the IESG/ADs ability to make longer than 30-day suspensions
and to engage in alternate methods of mailing list control, as
described in 2418.
I agree that the IESG having only the option of 1 year
Joel == Joel M Halpern [EMAIL PROTECTED] writes:
Joel After re-read Brian's draft, RFC 3683, RFC 3934, and the
Joel relevant portions of RFC2418 I support the IESG/ADs ability
Joel to make longer than 30-day suspensions and to engage in
Joel alternate methods of mailing list
3GPP owns the IMS specification, not the IETF. I know there was a recent
contribution to 3gpp for using STUN (and TURN and ICE) for NAT traversal.
In the IETF, STUN is a standard (RFC3489), TURN is being standardized in the
BEHAVE working group and ICE (which is related to STUN and TURN) is
Andrew,
Let me suggest, and suggest to the Nomcom, that these
requirements are the opinions of the incumbents of what it
takes to do the jobs as they see them. That is important
input, but I question whether it should be controlling for
either applicants or Nomcom decisions. In particular,
On Oct 19, 2006, at 2:53 PM, John C Klensin wrote:
I believe that potential candidates who (i) clearly understand what
is involved in the relevant role but (ii) who have plausible ideas
about how the tasks could be rearranged so as to reduce the
workload should be taken very seriously
Sam Hartman wrote:
I'm going to last call the draft again.
The discuss was about -02, the new last call will be about
-03, here's a tiny URL for a diff: http://tinyurl.com/y6c2nk
The iesg-discuss-criteria-02 I-D could be updated, it expired
two months ago, and there's apparently a bug in its
On Friday, October 20, 2006 04:01:13 AM +0200 Frank Ellermann
[EMAIL PROTECTED] wrote:
For the draft in question that means that it's now at 12:2, and
if one member changes his or her mind it could fail with a 11:3.
You are confusing the normal balloting process with the alternative one.
Total of 115 messages in the last 7 days.
script run at: Fri Oct 20 00:03:01 EDT 2006
Messages | Bytes| Who
+--++--+
8.70% | 10 | 7.96% |53526 | [EMAIL PROTECTED]
7.83% |9 | 6.56% |44090 | [EMAIL
At 11:12 PM -0400 10/19/06, Jeffrey Hutzelman wrote:
(presumably, an IESG member having only weak objections would enter an
abstain,
This is not what an abstain means in the IESG's procedures.The text
from http://www.ietf.org/u/ietfchair/voting-procedures.txt says:
- Abstain means I
Jeffrey Hutzelman wrote:
You are confusing the normal balloting process with the alternative one.
s/confusing/comparing/ - assuming that yes + no objection end up as yes,
and discuss + abstain as no. Skipping Brian's R to get 14 ballots.
there is no reason to assume that someone who voted
The IESG has received a request from the IS-IS for IP Internets WG to
consider the following document:
- 'IS-IS Extensions for Advertising Router Information '
draft-ietf-isis-caps-06.txt as a Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits
final
The IESG has received a request from an individual submitter to consider
the following document:
- 'Additional ECC Groups For IKE and IKEv2 '
draft-ietf-ipsec-ike-ecc-groups-10.txt as an Informational RFC
The IESG plans to make a decision in the next few weeks, and solicits
final comments on
The IESG has received a request from the Open Shortest Path First IGP WG
to consider the following document:
- 'Multi-Topology (MT) Routing in OSPF '
draft-ietf-ospf-mt-06.txt as a Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this
The IESG and IAB provide the NomCom with requirements for the positions in
their groups.
To help nominators select good candidates, and let the community know the
sorts of experience and qualifications that the NomCom is seeking, the
requirements have been posted at the URLs below.
Requirements
The previous call contained a typo. Lars Eggert was erroneously listed as
a Security AD instead of Transport AD. The corrected list is below.
The IESG positions that will be reviewed by this NomCom are:
Brian Carpenter -- General Area (IETF Chair) Ted Hardie -- Applications
Area Mark Townsley
The IESG has received a request from the Ethernet Interfaces and Hub MIB
WG to consider the following document:
- 'Definitions of Managed Objects for IEEE 802.3 Medium Attachment
Units (MAUs) '
draft-ietf-hubmib-rfc3636bis-05.txt as a Proposed Standard
The IESG plans to make a decision in
The NeuStar Secretariat Services annual power generator maintenance for
the data center will be taking place over this weekend.
As a consequence of this routine maintenance, between Saturday, October
21, 2006, 5pm EDT, and Sunday, October 22, 2006, 2am EDT, the following
sites and services may
A new Request for Comments is now available in online RFC libraries.
RFC 4711
Title: Real-time Application Quality-of-Service Monitoring
(RAQMON) MIB
Author: A. Siddiqui, D. Romascanu,
E. Golovinsky
A new Request for Comments is now available in online RFC libraries.
RFC 4710
Title: Real-time Application Quality-of-Service Monitoring
(RAQMON) Framework
Author: A. Siddiqui, D. Romascanu,
E. Golovinsky
A new Request for Comments is now available in online RFC libraries.
RFC 4712
Title: Transport Mappings for Real-time Application
Quality-of-Service Monitoring (RAQMON) Protocol Data
Unit (PDU)
Author: A.
Addendum to the previous annoucement that is attached below:
In extreme condition, IETF Mail Exchange server will automaically
failover to the secondary MX server that is running from other data
center, which will assure that there will be *no* impact on email exchange
(include I-D submissions)
Overflow hotels have been arranged and are within five miles (15 minutes
by cab). Both have agreed to favorable rates especially given the high
demand for the rooms. Information on two additional hotels has been added
to the IETF website: http://www.ietf.org/meetings/67-hotels.html. Rooms
are
All revised Internet-Drafts (version -01 and higher) must be submitted
by Monday, October 23rd at 9:00 AM ET.
Revised Internet-Drafts received after the cutoff date will not be made
available in the Internet-Drafts directory or announced until on or
after Monday, November 6th at 9:00 AM ET,
31 matches
Mail list logo
