--On Saturday, April 16, 2011 07:51 -0700 Lucy Lynch
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 appoint from ou
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 :
>
> The IESG has received a request from the Speech Services Control W
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 h
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 procedur
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 s
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? Wheth
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 Minne
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 arrangem
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. H
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 Tr
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,
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 th
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 com
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
e
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 enableme
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 Internet
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 basicall
17 matches
Mail list logo
