Dear all,
Thanks for this important, which I support.
In section 2, I would add that only a few protocols moved from Proposed
Standard to Internet Standard, even if those protocols were widely
deployed in the Internet. This proves the points that:
1. the specifications were stable
2. the
John,
--On Wednesday, July 24, 2013 09:22 +0300 IETF Chair
ch...@ietf.org wrote:
I wanted to let you know about an experiment we are trying out
in Berlin.
...
But we want as many people as possible to become involved in
these efforts, or at least provide their feedback during the
week. So we
Forwarding to the authors and WG
Regards, Benoit
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq.
Please resolve these comments along with any other Last Call comments
you may receive.
Forwarding to the authors and WG
Regards, Benoit
I am guessing that the authors intended the addition of the text
emphasizing that the no-zone typedefs are derived general typedef
addresses the difference in the patterns.
Is there a YANG rule that says tat if typedef X is derived from
On 2/05/2013 18:17, Carsten Bormann wrote:
On May 2, 2013, at 07:21, Eggert, Lars l...@netapp.com wrote:
Yeah, all kinds of issues, but if we created a new thing here in between WGLC
and PS, the broader industry would never understand.
That is a matter of naming and marketing (candidate
Thomas,
Good point. I guess the obvious answers are not enough
cycles and, for newer authors, uncertainty about how to
get stuff done, but are there other less obvious answers?
(Input here might really help the IESG discussion btw since
in the nature of things, we're less likely to realise what
On May 1, 2013, at 1:59 PM 5/1/13, Dave Crocker d...@dcrocker.net wrote:
The blog nicely classes the problem as being too heavy-weight during final
stages. The quick discussion thread seems focused on adding a moment at which
the draft specification is considered 'baked'.
I think that's
Hi Jouni,
Jari,
This was an interesting (and a needed) writeup. I also want to share
my view as an IETF newbie who has had a chance to experience IETF
document process a few times. Sorry for chiming in late..
For the most part I got the feeling that we have the right tools and
a working
Thanks Dave for your thorough review.
You have some very valid points.
I've not seen any replies from the author. Maybe he doesn't monitor this
list. So, including some extra mailing lists.
Martin, NETMOD WG, can you please address David's points.
Note: there is also a reply from Tom Petch on
Martin,
It's interesting to note that Dave came up with similar feedback as I
had during my AD review.
And you had to re-explain this again, via email. This leads me to think
that we need some more background information, typically in Operational
Considerations section.
On 30/04/2013 13:07, Benoit Claise wrote:
Martin,
It's interesting to note that Dave came up with similar feedback as I
had during my AD review.
And you had to re-explain this again, via email. This leads me to
think that we need some more background information, typically in
Operational
Joel,
Thanks for your review.
Minor issues:
If compliance is a big issue, then this document seems
under-specified. For example, it says in section 5.1 In order to be
compliant with this document, at least the Property Match Filtering
MUST be implemented. However, Property Match
:*Benoit Claise [mailto:bcla...@cisco.com]
*Inviato:* lunedì 8 aprile 2013 15:21
*A:* draft-ietf-ipfix-flow-selection-t...@tools.ietf.org
*Cc:* ipfix-cha...@tools.ietf.org
*Oggetto:* Fwd: Last Call Expired:
draft-ietf-ipfix-flow-selection-tech-14.txt
Dear authors,
The IETF last call has finished
Dear authors,
While reviewing draft-ietf-ipfix-mediation-protocol, Rahul got some
feedback that actually concerns draft-ietf-ipfix-flow-selection-tech.
Can you please take this into account.
Regards, Benoit
Few comments.
1. Page 8:
1. The difference between Intermediate Selection
I'm really, really against turning this into an election-like process
just because one nomcom did a bad job (and I agree they did).
I've puzzled by this statement nomcom did a bad job.
How could we, people outside of noncom, know that they did a bad job?
They are the only ones who have all the
On 5/03/2013 00:49, Spencer Dawkins wrote:
On 3/4/2013 2:31 PM, Mary Barnes wrote:
As far as I can tell, the last official Nomcom report was from the
Nomcom I chaired (2009-2010):
http://tools.ietf.org/id/draft-barnes-nomcom-report-2009-00.txt
I have a general question for the community as to
On 4/03/2013 15:57, John Leslie wrote:
Eggert, Lars l...@netapp.com wrote:
On Mar 4, 2013, at 13:18, Eric Burger ebur...@standardstrack.com wrote:
I will say it again - the IETF is organized by us. Therefore, this
situation is created by us. We have the power to fix it. We have to
want to fix
grown
over the years.
Alia
On Mon, Mar 4, 2013 at 6:05 PM, Benoit Claise bcla...@cisco.com wrote:
On 4/03/2013 15:57, John Leslie wrote:
Eggert, Lars l...@netapp.com wrote:
On Mar 4, 2013, at 13:18, Eric Burger ebur...@standardstrack.com wrote:
I will say it again - the IETF is organized
Hi Jari,
The IESG has received a request from an individual submitter to consider
the following document:
- 'Experiences from Cross-Area Work at the IETF'
draft-arkko-iesg-crossarea-02.txt as Informational RFC
The IESG plans to make a decision in the next few weeks, and solicits
final
Some more feedback, send on behalf of Al Morton.
Regards, Benoit
=
Hi Benoit,
Here are some additional comments, just checking a few things
I know a little about.
Al
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
1.1. The Building Blocks of OAM
...
o
draft-ietf-opsawg-oam-overview authors,
Here is my feedback on this document.
1.
Is this document in line with
http://tools.ietf.org/html/draft-ietf-trill-oam-req-04?
* For example, the following definitions could be reused.
Fault: The term Fault refers to an inability to perform a
Dear all,
Please note that version 8 has just been posted.
Regards, Benoit
The IESG has received a request from the RADIUS EXTensions WG (radext) to
consider the following document:
- 'Remote Authentication Dial In User Service (RADIUS) Protocol
Extensions'
Hi Roni,
[keeping only the open discussions]
Hi Benoit,
Thanks, see in-line
Roni
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq.
Please resolve these comments along with any
Hi Roni,
Thanks for your review.
See in-line.
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq.
Please resolve these comments along with any other Last Call comments
you may receive.
Dear all,
Because dataLinkFrameSize and dataLinkFrameSection have been removed,
the editor renumbered all the I.E. assignments.
That could generate some problems for existing implementations, if any.
However, I can live with that.
However, where there is a bigger problem is that IANA is
Dan,
Thanks for your review. I will address all your comments for in the next
version. However, I don't plan to have a new version before the
Transport Area directors have reviewed the doc (they asked for an
extended deadline)
Please quickly evaluate if you agree with the proposed changes.
26 matches
Mail list logo
