Henry,
I believe that's a perception issue, and I would invite you and other folks to a more
attentive read of the RAQMON documents. They are actually in WGLC, so it's a good
moment, and comments are very welcome.
RAQMON has nothing to do with network elements like routers or similar.
This BOF is yet to appear on the formal agenda for IETF-61. FYI in advance
of the agenda being made available.
-Scott-
--
BOF Chairs:
Howard Eland [EMAIL PROTECTED]
Patrik Fältström [EMAIL PROTECTED]
BOF Description:
IDN-over-EPP
As the global DNS applications and Top-Level Domain
Brian,
While this shouldn't be viewed as legal advice on the issue, it is my
understanding that, in general, members of an unincorporated association
(and participants in IETF activities may be viewed as members) will have
personal liability for the authorized debts and actions of the
Sorry, but it is inappropriate for anyone, even a lawyer, to say on
an open mailing list While this shouldn't be viewed as legal advice
and follow it with scary legal-sounding advice. We've heard it before
in the IETF on various issues, mostly patent law, and it has often
turned out to be
Hi Patrice,
Just FYI --
The Internet Society currently holds a liability insurance policy
that covers the IETF Chair, IESG members, IAB members, NomCom
members, WG chairs (and maybe others that I am forgetting). This
insurance is intended to protect IETF leaders and decisions makers
from the
I am one more question on SIP REGISTER mechanism.
1) The phone sends REGISTER to say server1. Can
register1 send 302 response to the phone asking the
phone to register with server2?
2) Can sip server force the phone to re-register?
Meaning, can the server1 ask the phone to register
with a new
| -Original Message-
| From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
| On Behalf Of Patrice Lyons
| Sent: Wednesday, November 03, 2004 2:34 AM
| To: Brian E Carpenter
| Cc: [EMAIL PROTECTED]
| Subject: Re: I-D ACTION:draft-lyons-proposed-changes-statement-01.txt
|
| Brian,
|
| While
The Problem Statement (problem) in the General Area has concluded.
The IESG contact person is Harald Alvestrand.
With the publication of RFC 3774 and RFC 3844, the work of the Problem WG
is at an end, and the group is therefore closed.
On behalf of the IETF, the AD wishes to thank all who
The AToM MIB (atommib) in the Operations and Management Area has concluded.
The IESG contact persons are Bert Wijnen and David Kessens.
The mailing list will remain active.
+++
The AtomMIB WG has delivered part of their work items and as a result
a number of new RFCs were published on the
The IESG has approved the following document:
- 'Additional XML Security URIs '
draft-eastlake-xmldsig-uri-09.txt as a Proposed Standard
This document has been reviewed in the IETF but is not the product of an
IETF Working Group.
The IESG contact person is Russ Housley.
Technical Summary
Greetings,
The RFC Editor will be holding office hours at IETF-61 Washington,
DC. This is a chance for a face-to-face inquiry into the status of
pending documents or just a chance to ask questions about how the RFC
Editor works. The RFC Editor office will be a table near the IETF
registration
11 matches
Mail list logo
