-
From: Gonzalo Camarillo [mailto:gonzalo.camari...@ericsson.com]
Sent: Monday, September 16, 2013 3:04 PM
To: Glen Zorn
Cc: Romascanu, Dan (Dan); Qin Wu; draft-ietf-xrblock-rtcp-xr-
qoe@tools.ietf.org; Shida Schubert; rai-...@tools.ietf.org; The
IESG; ietf@ietf.org
Subject: Re: IPR
Well, this is a cultural thing :-) Some of our American colleagues cannot avoid
using examples related to the American constitution, history or academy,
forgetting that out-of-the-US interlocutors may not that familiar with them.
Luckily, they did not mention any baseball rule in this
Hi,
I agree with Warren and disagree with Pete on this issue.
Of course, adding more arguments, being more verbose when expressing support is
very useful. However, I consider the brief comments like the one made by Russ
useful - at least in determining consensus. I am actually encouraging
Hi Steve,
We shall ask the question, but I can already guess the answers. Current IEEE
rules (copyright rules I think) do not allow for sharing of work-in-progress
drafts with no access control. You need to be a participant of some sort in
order to access such documents, and this validated
Hi,
Good work. Here are a few thoughts after a first reading.
- We seem not to have a definition of what a WG I-D is, although we know how to
recognize a WG I-D because of the naming convention. So, if I am not mistaken
the phrase
Working Group drafts are documents that are subject to IETF
I like it a lot!
Starting with IETF-87 I will reserve a breakfast slot for the WG I am
co-chairing and invite (in advance, the week before the meeting) the new
attendees interested in this WG to attend.
Regards.
Dan
-Original Message-
From: ietf-boun...@ietf.org
-Original Message-
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of
Yoav Nir
Sent: Thursday, March 14, 2013 4:30 PM
To: Ted Lemon
Cc: John C Klensin; adr...@olddog.co.uk; IETF-Discussion list; The
IESG
Subject: Re: Mentoring
On Mar 14, 2013, at 10:03
Klensin [mailto:john-i...@jck.com]
Sent: Thursday, March 14, 2013 4:43 PM
To: Romascanu, Dan (Dan); Ted Lemon; Mary Barnes
Cc: adr...@olddog.co.uk; IETF-Discussion list; The IESG; Shida
Schubert
Subject: RE: Mentoring
--On Thursday, 14 March, 2013 14:07 + Romascanu, Dan (Dan)
droma
We had such a WG-Chairs session dedicated exactly to this topic (document
shepherding) at IETF-82 - including a panel of document shepherds and ADs
sharing experience and discussing ways to improve the process and make the
shepherds role more efficient.
Dan
-Original Message-
I believe that Adrian did right in this case. This was IMO one of the
situations which in Spencer's language was 'middle path between lightweight
IESG decisions and full process BCP revisions' and a 3933 experiment could have
proved it right or wrong, useful or not. The community could not
This is a useful and well-written document and I support its publication. I
have a few comments which I would be glad if they were addressed:
1. I believe that the document must include reference to TRILL OAM, referencing
draft-ietf-trill-oam-req-04 (which is close to approval) and including a
Hi,
I believe that this is a good document and I support its approval.
I do have a number of issues which I suggest to take into consideration before
approval and publication:
1. In Section 4:
The SIP CLF is amenable to easy parsing and lends itself well to
creating other innovative
+1
The length of the written mail list track of a document is only one indicator.
It's an important one, but it should not be treated as absolute. Sometimes 2-3
people debated one obscure aspect of the document in tens of messages.
In the case when a document generated zero or very little
Hi Barry,
There is a disconnect between what the Last Call is asking and what you
really seem to be asking as a feedback.
The Last Call question is:
The IESG has received a request from an individual submitter to
consider the following document:
- 'Document Shepherding Throughout a
Hi,
The OPSAWG/OPSAREA open meeting this afternoon has an item on the agenda
concerning the revision of RFC1052 and discussing a new architecture for
management protocols.
My personal take is that no one protocol, or one data modeling language
can match the operational requirements to
Yes. The question is whether a basic information model written in XML can be a
useful starting point (trying to interpret the proposal made by Robert).
Dan
-Original Message-
From: Andy Bierman [mailto:a...@yumaworks.com]
Sent: Thursday, August 02, 2012 8:14 PM
To: Romascanu, Dan
(I hope not to open some Pandora box or a long thread - my goal is to
make sure there is clarity in the language of the statement)
What 'IETF protocol specification' means here?
Pretty clear it covers protocols defined in IETF standards-track
documents.
Does it also cover protocols defined
Overall this is a good document and I support its approval. A few items
should be clarified before approval, please see below:
1. In the introduction:
In addition,
IPv6 provides tools for autoconfiguration, which is particularly
suitable for sensor network applications and nodes which
Hi,
The inclusion of the template as an Appendix in the document is
confusing - right now A.1 through A.7 define sections in the future
I-Ds, while A.8 and A.9 describe appendices in the future I-D. This
document has two sections each titled Appendix A and Appendix B.
Moreover, this inclusion
This would be fine with me.
Dan
-Original Message-
From: jouni korhonen [mailto:jouni.nos...@gmail.com]
Sent: Monday, January 16, 2012 4:50 PM
To: Stephen Farrell; Romascanu, Dan (Dan)
Cc: Jouni Korhonen; lionel.mor...@orange-ftgroup.com Morand;
d...@ietf.org; IETF-Discussion; i
Hi,
If a number of hands were raised now and the folks commanding them say
'we are ready to work on this NOW' I would support including explicit
wording in the charter. If this does not happen until the telechat next
week the current text is good enough to allow interested people to start
working
Thanks, Glen! Can we see (at least) a couple of more hands from people willing
to participate in the editing of this document?
Dan
-Original Message-
From: Glen Zorn [mailto:glenz...@gmail.com]
Sent: Fri 1/13/2012 5:34 AM
To: Romascanu, Dan (Dan)
Cc: Stephen Farrell; jouni korhonen
Hi Keith,
Ø The only other formal level of review we have are the Last Call comments
which, given the volume of documents that get Last Called, amounts to a fairly
small and random chance that somebody outside the WG will happen to notice the
proposed document action and give the document
Hi Thomas,
The paragraph below does not belong to me. In my message I was actually
answering it.
Regards,
Dan
-Original Message-
From: Thomas Narten [mailto:nar...@us.ibm.com]
Sent: Monday, August 15, 2011 3:51 PM
To: Romascanu, Dan (Dan)
Cc: Keith Moore; Barry Leiba; adr
Hi Mark,
The scope of the new mail list is much more restricted than the one of
the clouds list.
I acknowledge that there is a balance we all need to keep within
reasonable limits between many too focused lists and lesser more general
lists. My opinion is that it's better to discuss on lists
Hi Stefan,
Thank you for the comment and sorry for the taking a few days to answer this,
but your comment generated some discussions within the IESG, which are still
ongoing.
There was no IPR disclosure made directly on draft-ietf-dime-rfc3588bis-25.txt,
and this is why the IETF LC does not
The VIPR WG will address this problem by developing a peer to
peer based approach to finding domains that claim to be
responsible for a given phone number and validation protocols
to ensure a reasonable likelihood that a given domain
actually is responsible for the phone number.
Hi,
.
Dan
-Original Message-
From: Mary Barnes [mailto:mary.ietf.bar...@gmail.com]
Sent: Wednesday, June 30, 2010 6:24 PM
To: Romascanu, Dan (Dan)
Cc: DISPATCH; IETF-Discussion list
Subject: Re: [dispatch] VIPR - proposed charter version 3
Hi Dan,
The term peer to peer is intended
A new alias has been created for discussion on this topic:
clo...@ietf.org mailto:clo...@ietf.org .
Do you mean a mail list? Can you provide subscribe information?
Thanks and Regards,
Dan
From: ietf-boun...@ietf.org
We can ask the Secretariat to gather the current schedules of the
different areas open hours and post them on this list, on the
76attendees list, and on the announcement board at the meeting. By doing
this a relevant number of people will be reached, I think.
FWIW, the OPS AD's are holding the
The OPSAWG discusses a proposal to reclassify COPS-PR and SPPI to
Historic, based on an I-D authored by Juergen Schoenwaelder -
http://www.ietf.org/id/draft-schoenw-opsawg-copspr-historic-01.txt . Any
input about implementation and deployments of COPS-PR, SPPI and PIB
modules should be sent to
Steve, I believe that the situation is #1 below.
Dan
-Original Message-
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On
Behalf Of Stephen Hanna
Sent: Thursday, August 13, 2009 1:53 PM
To: Tom.Petch; sec...@ietf.org; ietf@ietf.org;
-Original Message-
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On
There is currently a Secdir review for Internet-Drafts. If
operations and management considerations are included, the
documents will need an Opsdir review and a mandatory
Management
Sam,
Thank you for your review and opinions.
I would like to remind you and let many people that are not aware about
the history of the document know one fact that may be important. This
document is an outcome of the discussions hold at the IESG retreat in
May 2006. I was then the 'fresh' AD
Hi Sam,
A clarification and a clarification question in-line.
Dan
-Original Message-
From: Sam Hartman [mailto:hartmans-i...@mit.edu]
Sent: Thursday, June 04, 2009 2:23 PM
To: Romascanu, Dan (Dan)
Cc: Sam Hartman; ietf@ietf.org; ops...@ietf.org
Subject: Re: Last Call:
draft
Cullen,
The current allocation policy is defined by RFC 3588, section 11.2.1
which indeed makes no distinction between permanent, standard commands
and vendor-specific command codes and requires IETF consensus for all.
This will be fixed by
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of [EMAIL PROTECTED]
Sent: Wednesday, September 03, 2008 3:03 PM
To: [EMAIL PROTECTED]
Cc: ietf@ietf.org
Subject: RE: Gen-ART Review of draft-ietf-forces-mib-07
Olaf Kolkman rote:
Personally I
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Joel Jaeggli
From the perspective of the panopticon that the centrally
managed wireless controller model offers, some wireless users
experienced fairly chronic issues, most did not. I'd love
-Original Message-
From: David Kessens [mailto:[EMAIL PROTECTED]
Sent: Tuesday, August 05, 2008 2:18 PM
To: Romascanu, Dan (Dan)
Cc: Joel Jaeggli; Henning Schulzrinne; IETF Discussion
Subject: Re: Proposals to improve the scribe situation
Dan,
On Tue, Aug 05, 2008 at 12
Speaking as an individual who has also participated in the work of other
standards organizations - In other SDOs, the IEEE 802 for example,
suggesting a fix for a problem detected in the text at ballot time is
not only welcome, but sometimes the recommended if not mandatory
practice.
Dan
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Joel M. Halpern
Sent: Saturday, May 31, 2008 3:12 AM
To: IETF Discussion
Subject: Re: Guidelines for authors and reviewers
Comment inline, with most of the discussion elided. I
believe that
I would like to congratulate the editors for the inclusion and content
of the Manageability Consideration section. It is well written, and
includes detailed information that will be very useful for implementers
as well as for operators who will deploy the protocol.
One nit: in section 8.6
1. The MIB compiles cleanly.
2. idnits detected three documents in the references that were already
published as RFCs:
== Outdated reference: draft-ietf-pim-mib-v2 has been published as RFC
5060
== Outdated reference: draft-ietf-pim-sm-bsr has been published as RFC
5059
== Outdated
Besides the suggestion already given, if you go to
http://www.rfc-editor.org/rfcsearch.html start with a search on IMAP.
RFC1730 will be one of the first (in chronological order) of the 47
entries, you will find out in the More Info columns that it was
obsoleted by RFC2060 and RFC2061. RFC2060
-Original Message-
From: Joel M. Halpern [mailto:[EMAIL PROTECTED]
The first of the two comments below is probably
primarily the IESG's concern, although it affects the IETF last call.
The second comment is a more general issue.
Comments:
This document
The current version of the document completely lacks any information
regarding manageability of networks that run IP over IEEE 802.16. At a
minimum I would expect a short discussion about the interfaces model of
an IP over 802.16 or have the definition of such a model as well as of a
standard
In both sessions in the afternoon that I attended (ipfix, opsawg) people
who were on jabber and listening to audio streams complained about
repeated interruptions in the audio feed.
Dan
-Original Message-
From: Joel Jaeggli [mailto:[EMAIL PROTECTED]
Sent: Wednesday, December
Here are my comments. They are quite a few, it may be because it's a
good document.
Technical:
1. Section 3.2.1 - Packet Content. The definition includes in the packet
header the link layer header. This deserves at least a note, which
should draw the attention on the fact that some if the
Please find below my technical and editorial comments:
Technical
1. Section 3.1 - Packet Content. The definition includes in the packet
header the link layer header. This deserves at least a note, which
should draw the attention on the fact that some if the Observation Point
is located at the
Here are my Technical and Editorial comments:
T1: page 19, Section 6.1 -
The Metering Process must support inclusion of the following in
each Packet Report, as a configurable option:
(iii) a basic report on the packet, i.e., some number of
From: Gabriel Montenegro [mailto:[EMAIL PROTECTED]
Sent: Monday, October 08, 2007 6:20 PM
To: Romascanu, Dan (Dan); Eliot Lear; Eric Rescorla
Cc: Jari Arkko; ietf@ietf.org; [EMAIL PROTECTED]
Subject: RE: Comments on draft-aboba-sg-experiment-02
The way I see it the problem that this proposal tries to solve is about
helping the IESG and the community to make a better decision when the
forming of the working group us discussed. It is not about bringing more
work to the IETF, it is about making sure to a better extent that the
right work is
Yes, and this translates in IETF speech into having a viable technical
concept which is caught in a sound charter, proved resources and
community interest plus early code and individual I-Ds as very desirable
additions.
A SG process would not replace those, but could help achieve them in a
more
Scott,
Please note the note included in the IETF Last Call:
A previous version draft-ietf-ipfix-protocol-24.txt of this draft was
already approved by the IESG. The IPFIX WG decided to make changes to
that version of the document with the principal goal of removing the
SCTP stream 0
Please find below the MIB review performed by MIB Doctor Dave Thaler.
Dan
---
I have completed my MIB doctor review of this document.
Comments below.
1) The RFC 2119 boilerplate is currently in section 2
The Internet-Standard Management Framework. However it
1.
'This document has
been produced to describe the report block in sufficient detail to
register the block type with IANA, rather than with the intention of
standardising the report block for use outside BT's network.'
Is this a recommendation not to use this report block outside a
See in-line.
Dan
-Original Message-
From: John C Klensin [mailto:[EMAIL PROTECTED]
Sent: Sunday, June 17, 2007 9:13 PM
To: Bernard Aboba; ietf@ietf.org
Subject: Re: Reforming the BOF Process (was Declining the
ifare bof for Chicago)
--On Tuesday, 12 June, 2007 09:52
the criteria for the initial decision more predictable.
Dan
From: Bernard Aboba [mailto:[EMAIL PROTECTED]
Sent: Friday, June 15, 2007 9:12 PM
To: Jari Arkko
Cc: Romascanu, Dan (Dan); ietf@ietf.org
Subject: RE: Reforming
Bernard,
Speaking as a participant in both the IETF and IEEE 802, there are many
things that I like in the CFI / Study Group process of IEEE. Your
proposal goes in the direction of solving one of the problems I perceive
in the IETF processes which is the lack of repeatability and
predictability
-Original Message-
From: Jari Arkko [mailto:[EMAIL PROTECTED]
Sent: Friday, April 06, 2007 9:13 AM
To: Simon Josefsson
Cc: Sam Hartman; ietf@ietf.org; Steven M. Bellovin
Subject: Re: In support of symbolic references
Simon,
Maybe we can lobby for it to become the
R is for Reasonable.
http://en.wikipedia.org/wiki/Reasonable_and_Non_Discriminatory_Licensing
Dan
-Original Message-
From: Frank Ellermann [mailto:[EMAIL PROTECTED]
Sent: Saturday, March 10, 2007 8:31 PM
To: ietf@ietf.org
Subject: Re: Last Call Comments on
To help Pekka here, from an operator's perspective the difference
between 'control' and 'management' is quite blurred, as long as the same
type of functionality happens in an operational deployment. Speaking as
an individual I believe that your approach may be correct, but it's
better that the
Please find below my comments:
1. The IETF LC mentions only the DOWNREF for RFC 3576. However, there is
another DOWNREF for RFC 2866 which is not mentioned in the LC.
2. Reference [1] fails to name the RFC number (2119)
3. It would be useful to include expansion of the acronyms at first
-Original Message-
From: John Cowan [mailto:[EMAIL PROTECTED]
SYNTAX OCTET STRING (SIZE (0..60))
be amended to exclude the 1-character case. I assume that a
zero-length tag, while also not defined in RFC 4646, was
included in
the I-D to allow the special
Mike's assessment seems reasonable to me.
Dan
-Original Message-
From: Gonzalo Camarillo [mailto:[EMAIL PROTECTED]
Sent: Tuesday, February 13, 2007 9:36 AM
To: C. M. Heard
Cc: IETF; Romascanu, Dan (Dan); GEN-ART
Subject: Re: Last Call: draft-heard-rfc4181-update (RFC 4181
1. The document should list 'Intended Status: Proposed Standard' in the
header
2. The document lacks an IANA consideration section. Moreover the
allocation of OptionType 22 in section 3.7.4 contradicts section 4.9.2
in RFC 4601 which states:
'OptionTypes 17 through 65000 are assigned by the
1. The header of the document should include: 'Intended Status -
Proposed Standard'
2. References problems:
- Unused Reference: 'RFC2586' is defined on line 2715, but not
referenced
'[RFC2586] Bierman, A., McCloghrie, K., Presuhn, R., Textual
Convent...'
- Unused Reference: 'RFC3636' is
The document has Intended Status of Standards Track but includes a
Normative Reference to RFC 3022 which is am Informative RFC. According
to RFC 3967, Section 3, the need for the downward reference explicitly
should have been documented in the Last Call itself. I believe that
either the Last Call
The CAPWAP WG will hold a two-day interim meeting. Here are the
details:
CAPWAP WG Interim Meeting
Wednesday Thursday, January 24 25, 2007 9:00am - 5:00pm (PDT) 3750
Cisco Way (Building 15) San Jose, CA, USA
More information about the CAPWAP WG can be found on our charter page:
The CAPWAP WG will hold a two-day interim meeting. Here are the
details:
CAPWAP WG Interim Meeting
Wednesday Thursday, January 24 25, 2007 9:00am - 5:00pm (PDT) 3750
Cisco Way (Building 15) San Jose, CA, USA
More information about the CAPWAP WG can be found on our charter page:
1. I find the security considerations section to be incomplete. What is
missing is a description of the security risks encountered by the
malicious or accidental mis-configuration of the read-write objects that
are listed. For example ' Changing dot3MpcpAdminState state can lead to
disabling the
Hi,
I suggest that you subscribe and address your questions at
[EMAIL PROTECTED]
You may want to describe what are you exactly trying to load and do, and
also why you are trying to use the old SMI version rather than the new
version SMIv2 defined by RFC 2578.
Dan
-Original
I read this document and in general I believe that it's well and clear
written. I have a couple of technical issues and a few editorial nits
1. The document is sharing allocation space and refers in several places
to [LSP-Ping] which is also listed as a Normative Reference. I could not
however
In order to increase the efficiency of the work in the CAPWAP Working
Group (http://www.ietf.org/html.charters/capwap-charter.html), and in
order to accelerate the consensus process in the Working Group, the Area
Directors decided to create a third co-chair position for the CAPWAP WG.
The ADs
Does this mean that audio streaming, including recording will be
available also for the EDU sessions scheduled for the afternoon of
Sunday, 7/9?
Thanks,
Dan
-Original Message-
From: Joel Jaeggli [mailto:[EMAIL PROTECTED]
Sent: Saturday, June 24, 2006 11:22 PM
To:
Please find below my comments:
1. The orientation of the document seems to be very IPv6 centric. Yes,
there is a 'IPFIX and IPv6' section, but it's very limited in scope, and
then all examples in the text use IPv4 addresses for example. I suggest
that at least a note is included in the 'IPFIX and
Please read 'very IPv4 centric' rather than 'very IPv6 centric' in the
first paragraph.
Dan
-Original Message-
From: majordomo listserver
[mailto:[EMAIL PROTECTED] On Behalf Of Romascanu, Dan (Dan)
Sent: Thursday, June 22, 2006 3:39 PM
To: iesg@ietf.org; ietf@ietf.org
Cc
Yaakov,
The very next paragraph that follows the one that you are quoting from
RFC 3935 talks about the cardinal principles that the IETF is
undertaking in order to fulfill its mission. The first principle in the
list is Open Process. My interpretation is that while creating tools for
tools seek
FWIW - if this is the case, this policy is in the
disadvantage of the participants coming from out of North America for both IEEE
and IETF meetings. We shall be obliged to do two trips instead of one which
doubles airfare costs andrequires fromus to at least one
supplemental weekend on the
From: Ray Pelletier
[mailto:[EMAIL PROTECTED] Moreover adjacency cannot be
avoided with 34 groups and 52 weeks.
[DR]Actuallyfromthe perspective of
aparticipant from a different continent than North America adjacency
of meetings scheduled in North America is
-Original Message-
From: Pekka Savola [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 16, 2006 8:04 AM
To: Hallam-Baker, Phillip
Cc: ietf@ietf.org; Keith Moore; iesg@ietf.org;
[EMAIL PROTECTED]; Jeffrey Hutzelman
Subject: policy enforcement points and management [RE: Last
-Original Message-
From: Hallam-Baker, Phillip [mailto:[EMAIL PROTECTED]
I don't think that the current meetings are power-point laden
summaries, but that would actually be useful. I often end up
going to sessions at conferences to find out what a WG is
intended to
All that aside, the IANA has a distinction (based on history)
between ports below 1024 and those above. And whne asking
for a port number assignment, one specifies which range one
wants. I had least can not find a coherent strategy for what
should be on one side or the other of that
Please find below my Last Call comments to this document. I believe that
the document is close to completion, but there still are a number of
rather consistent edits that I would rather see dealt in a new version.
As the document includes quite extensive discussions of IPR transfer
issues, I
http://www.ietf.org/ietf/1id-guidelines.html
Regards,
Dan
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
ChandraMohanSent: Wednesday, December 28, 2005 3:06
PMTo: ietf@ietf.orgSubject: Need to know the
procedure
Hi
I would like to know the
: Saturday, November 12, 2005 7:11 AM
To: Romascanu, Dan (Dan); Avri Doria; Ole Jacobsen
Cc: ietf@ietf.org
Subject: Re: Please make sure that you do not run your
WLAN in ad hoc
mode
On Sat, 12 Nov 2005 06:45:59 +0200
Romascanu, Dan \(Dan\) [EMAIL PROTECTED] wrote:
Dear Dan
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Avri Doria
Sent: Saturday, November 12, 2005 4:15 AM
To: Ole Jacobsen
Cc: ietf@ietf.org
Subject: Re: Please make sure that you do not run your WLAN
in ad hoc mode
On 11 nov 2005, at
PROTECTED]
Sent: Saturday, November 12, 2005 7:11 AM
To: Romascanu, Dan (Dan); Avri Doria; Ole Jacobsen
Cc: ietf@ietf.org
Subject: Re: Please make sure that you do not run your WLAN
in ad hoc mode
On Sat, 12 Nov 2005 06:45:59 +0200
Romascanu, Dan \(Dan\) [EMAIL PROTECTED] wrote:
Dear
Actually I prefer this schedule because it does not call me for a night
session after dinner, and I suspect that many people coming from
European time zones may feel the same. As Ole points out, availability
of coffee during the afternoon sessions would help us make it easier
through the long
As a quasi-permanent time-zone challenged participant, I agree with
Andy. I like this schedule much better, and I am all in favor having
dinner (or going to sleep directly) after the last session in the
evening.
Dan
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Eric Tomson
Sent: Tuesday, June 07, 2005 1:33 PM
To: Prasanna S.J; ietf@ietf.org
Subject: RE: mac layer in manets
Prasanna,
No offense, but...
- The IETF is working on Internet
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Behalf Of Jeroen Massar
On Wed, 2005-04-06 at 11:52 +0200, Brian E Carpenter wrote:
Well, I thought I'd try something daring. We have people
arguing about xml versus nroff (again). If you write Internet
Drafts, try this toy (and only
I am attending lately both IETF and IEEE 802 Plenary meetings. Both run
networks of similar sizes, lately the IEEE 802 participation exceeds the IETF
one, but they are still at the same level of magnitude. I must say that
although the IEEE was late relative to the IETF in the game of providing
A (Anwar); Romascanu, Dan (Dan);
[EMAIL PROTECTED]; 'Madabhushi Pramod';
[EMAIL PROTECTED];
[EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: RE: [Sipforum-discussion] RE: Collecting media
statistics for SIP calls?
Folks,
Thats what RAQMON doesin a media gnostioc fashion.
RAQMON
See the RAQMON framework and RAQMON MIB, now in WGLC in the RMON MIB WG.
http://www.ietf.cnri.reston.va.us/internet-drafts/draft-ietf-rmonmib-raqmon-framework-07.txt
http://www.ietf.cnri.reston.va.us/internet-drafts/draft-ietf-rmonmib-raqmon-pdu-07.txt
I agree. This is not a SIP domain specific issue. See my previous answer pointing to
the real-time application QoS monitoring (RAQMON) work in the RMON MIB WG.
Regards,
Dan
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Behalf Of Thomas Gal
Sent: 31
You are correct if you refer to the participation numbers in last couple of meetings.
Historically IEEE 802 Plenaries have been much smaller in size than the IETF meetings.
I believe that by the time when the Hilton Head and Kauai meetings were hold (2001,
2002), the IEEE plenaries were
I do not believe that this is achievable. With the majority of other standards
organizations meetings and industry events building their schedules on a week basis,
avoiding major conflicts in the participants calendars would become an even more
challenging task, close to mission impossible.
Title: Converted from Rich Text
Note that the convention / group code is IEF and not IETF as
one may expect! It worked for me as well, but only on second try because of
this.
Regards,
Dan
-Original Message-From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]On Behalf
Title: Out of Office AutoReply: Possible SPAM Re: Your website
I am at the IEEE meeting and may not be able to read and reply to your message until May 23rd. If you need to contact me directly, please call +972-50-692-8065.
Regards,
Dan
1 - 100 of 113 matches
Mail list logo
