VeriLAN is going to check this computer on Wednesday (it's currently
located at a warehouse) to verify that all recordings were uploaded.
We'll know more shortly.
Alexa
On Apr 18, 2011, at 12:03 AM, Joel Jaeggli wrote:
On 4/14/11 8:22 PM, Scott Schmit wrote:
On Wed, Apr 13, 2011 at
--On Saturday, April 16, 2011 07:51 -0700 Lucy Lynch
lly...@civil-tongue.net wrote:
The implication is that the people sitting in the positions
of IAB Chair and IETF Chair are essential to the good
operation of the IAOC/Trust. Someone else from their groups
or even someone else that they
Hello,
my small comment:
The BARGE-IN-OCCURRED method is in few places wrote as BARGE-IN-OCCURED
(note missing R). I wonder how this could go through all 24 MRCPv2
revisions
Regards,
Slawek Testowy
2011/3/16 The IESG iesg-secret...@ietf.org:
The IESG has received a request from the
Hi!
Some other comments:
4.2. Managing Resource Control Channels
When the client wants to add a media processing resource to the
session, it issues a SIP re-INVITE transaction.
Is it possible to allocate more than one resource of the same type
during one SIP dialog? Example in 4.2 shows how
19.04.2011 1:21, Russ Housley wrote:
Mykyta:
4. Downward References Permitted
This section says nothing about references to documents with no status
(pre-IETF RFCs). Maybe informative references to such RFCs should be
allowed. And what about normative ones? Whether the RFC 3967 procedure
Mykyta:
4. Downward References Permitted
This section says nothing about references to documents with no status
(pre-IETF RFCs). Maybe informative references to such RFCs should be
allowed. And what about normative ones? Whether the RFC 3967 procedure
will be used in such cases, or
On 4/19/11 9:57 AM, Russ Housley wrote:
Mykyta:
4. Downward References Permitted
This section says nothing about references to documents with no status
(pre-IETF RFCs). Maybe informative references to such RFCs should be
allowed. And what about normative ones? Whether the RFC 3967
The IAOC is pleased to announce Vancouver,BC, Canada as the site for IETF
84 from July 29 to August 3, 2012. This will be the IETF's fourth meeting
in Vancouver, the others being 18, 64 and 70.
Google will be the the Host for this meeting. Google most recently was
the host for IETF 73 in
Bob, et al,
On 4/18/2011 2:25 PM, Bob Hinden wrote:
I didn't say no one else could do the job adequately. I said would have a
negative impact on the operations of the IETF.
Right. And my second sentence did go farther than I meant.
However rejecting an effort to change the current
I think this working group is a good idea.
My inclination would be to place it in the Applications area. It looks
like a nice application protocol to me.
There is a reasonable argument for placing it in RAI, as that is where
the relevant GEOLOC work has been done up till now.
Yours,
Joel M.
Hi Bob,
At 14:25 18-04-2011, Bob Hinden wrote:
I didn't say no one else could do the job adequately. I said would
have a negative impact on the operations of the IETF.
Some examples where an I* chair had a significant influence on a
decision that IAOC made include:
- The hiring of the
Dave,
On Apr 19, 2011, at 10:33 AM, Dave CROCKER wrote:
Bob, et al,
On 4/18/2011 2:25 PM, Bob Hinden wrote:
I didn't say no one else could do the job adequately. I said would have a
negative impact on the operations of the IETF.
Right. And my second sentence did go farther than I
On 4/19/11 1:47 PM, Paul Lambert wrote:
How does the area that the group is assigned impact the choices of
technology?
I'm an advocate for an efficient solution set for PAWS ... it will be
much like DNS for spectrum in the future and should be viewed as a
core infrastructural component
SM,
Eric Burger
Dave Crocker
Marshall Eubanks
Bob Hinden
Ray Pelletier (non-voting)
None of them are new to the IETF. If it requires I* Chairs for the IAOC to
be transparent, something is not right.
But that may not always be the case that all IAOC members have a lot of IETF
I think this is a good and timely thing for the IETF to do.
One part of this where I think it might be useful to get
some broader input (which may have happened already, I'm not
sure) is the following:
On 19/04/11 17:56, IESG Secretary wrote:
The protocol must protect both the channel
Clearly, the discussion about whether the application protocol should be
XML, plain ASCII/UTF8, binary, or some other encoding needs to take
place. But that can take place wherever we place the working group.
There is an argument, which you allude to, which would place this WG in
the
Actually, as far as I can tell, there is very little parallel between
the PAWS problem and SNMP.
SNMP tends to be initiated by the manager, and used to extract
information from the device in the network, or set information in teh
device.
This protocol is used by the client. It extracts
The Secure Inter-Domain Routing (sidr) working group in the Routing Area
of the IETF has been rechartered. For additional information, please
contact the Area Directors or the working group Chairs.
Secure Inter-Domain Routing (sidr)
---
Current
The IAOC is pleased to announce Vancouver,BC, Canada as the site for IETF
84 from July 29 to August 3, 2012. This will be the IETF's fourth meeting
in Vancouver, the others being 18, 64 and 70.
Google will be the the Host for this meeting. Google most recently was
the host for IETF 73 in
A modified charter has been submitted for the Softwires (softwire) working
group in the Internet Area of the IETF. The IESG has not made any
determination as yet. The modified charter is provided below for
informational purposes only. Please send your comments to the IESG
mailing list
A new IETF working group has been proposed in the Real-Time Applications
and Infrastructure Area. The IESG has not made any determination as yet.
The following draft charter was submitted, and is provided for
informational purposes only. Please send your comments to the IESG mailing
list
A new IETF working group has been proposed. The IESG has not made any
determination as yet. The following draft charter was submitted, and is
provided for informational purposes only. Please send your comments to the
IESG mailing list (i...@ietf.org) by Tuesday, April 26, 2011.
The IAOC is pleased to be able to announce sponsors for IETF 85 in Atlanta
in November 4 - 9, 2012. That meeting will be hosted by the North American
cable industry. The sponsoring companies are Comcast, Time Warner Cable,
CableLabs, the National Cable Telecommunications Association,
Brighthouse,
The IESG has received a request from the isms WG (isms) to consider the
following document:
- 'Transport Layer Security (TLS) Transport Model for the Simple Network
Management Protocol (SNMP) '
RFC 5953 as a Draft Standard
The IESG plans to make a decision in the next few weeks, and
The IESG has received a request from the isms WG (isms) to consider the
following document:
- 'Transport Subsystem for the Simple Network Management Protocol (SNMP) '
RFC 5590 as a Draft Standard
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this
The IESG has received a request from the isms WG (isms) to consider the
following document:
- 'Transport Security Model for the Simple Network Management Protocol
(SNMP)' RFC 5591 as a Draft Standard
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 opsawg WG (opsawg) to consider
the following document:
- 'Simple Network Management Protocol (SNMP) Context EngineID Discovery '
RFC 5343 as a Draft Standard
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this
27 matches
Mail list logo
