W. Mark Townsley wrote:
Rohit Gupta wrote:
Hi,
What is it in L2TP that i cant do with a simple GRE tunneling when
implementing a remote access
VPN for a mobile client to connect to the corporate network. In L2TP,
since it uses PPP
end-to-end, the LNS is able to supply dynamic IP address usin
scott bradner wrote:
the last time we talked about this Jorge said that he saw no problem
(legally) to just offer a takedown process to anyone who felt that
they did not want their ID to last longer than N days
but, to me, its quite silly to pretend that IDs actually disapear
from the net just bec
The IETF Meeting crew should look at supplying an additional 3 ethernet
and power drops per room, labelled 'chair', 'presenter' and '(jabber)
scribe' with the expectation that they be used accordingly. These
functions, IMHO, are too important to leave to the possible
failures/overloads of the wir
I would also be interesting to know how many use Microsoft Word
to produce drafts.
Stewart
Brian E Carpenter wrote:
Regardless of the interesting side-discussion about 'voting',
what the toy shows after about a day is:
prefer nroff: 8
prefer xml: 37
neither: 9
which implies a few hundred abst
Carl Malamud wrote:
Hi -
I think a research request to study how protocols are designed and features
added over time deserves a more accurate answer than an official
incantation of "they're gone."
Try this site:
http://www.watersprings.org/
You'll find all drafts and diff's between them.
T
end
result was that normative IETF text had "proper" drawings just like
IEEE and ITU.
Stewart
Regards,
Elwyn
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Stewart Bryant
Sent: 08 April 2005 10:47
To: Brian E Carpenter
Cc: [EMAIL PROTECTED]; B
Alexey Melnikov wrote:
Frank Ellermann wrote:
I'm working on other sort orders
Neither "REF" nor "IANA" in the "state" column before the date
could be very interesting. Or some statistics, but I guess
you already have that elsewhere.
Actually I disagree. It is quite useful to be abl
Andrew G. Malis wrote:
I'm with the folks that like this schedule. it's great being done for
the evening before dinner - it makes for a much more relaxed meal, and
you don't have to worry about going too far from the meeting. I also
remember that the Adelaide meeting, at least half of the
The IESG wrote:
The IESG has received a request from the Pseudo Wire Emulation Edge to Edge WG
to consider the following document:
- 'IANA Allocations for pseudo Wire Edge to Edge Emulation (PWE3) '
as a BCP
This draft reserves a number of ranges not be allocated by IANA,
for example i
I too use Subversion and rfcdiff and xml2rfc. But there are people
doing work (i.e. writing docs) in the IETF that do not work this way.
They may find using a version control system to be time-wise expensive
or prohibitive, especially compared to emailing track- change-docs back
and fort
Andrew Sullivan wrote:
On Mon, Nov 14, 2005 at 06:03:07PM +0200, Jari Arkko wrote:
There is. Lets not reopen the format flame war. However,
just for the record we DO have .pdf as a format that you
can submit Internet Drafts and as something that you
However these are not taken as normati
Yaakov Stein wrote:
It just struck me as odd that people were grousing about ASCII's
appearance when PDF is available.
People will stop complaining when the ASCII version is allowed to say
"see diagram in the PDF version".
Right on the nail
- Stewart
__
Bob Braden wrote:
*>
*> > It just struck me as odd that people were grousing about ASCII's
*> appearance when PDF is available.
*>
*> People will stop complaining when the ASCII version is allowed to say
*> "see diagram in the PDF version".
*>
*> Y(J)S
*>
Huh? That
Bob Braden wrote:
*>
*> Bob Braden wrote:
*>
*> > *>
*> > *> > It just struck me as odd that people were grousing about ASCII's
*> > *> appearance when PDF is available.
*> > *>
*> > *> People will stop complaining when the ASCII version is allowed to sa
*> >
It's interesting that when authors turn up at IETF to explain
their work/resolve issues etc they use colored diagrams
to do so - not ASCII art.
Some of this is fashionable, but in many cases it is to
clearly articulate a point in the very little time made available.
I don't see why such powerful
Masataka Ohta wrote:
Stewart Bryant wrote:
I don't see why such powerful techniques shouldn't
be applied to the specifications themselves to allow the reader
to most grasp what is being said with the minimum effort.
It merely promote complex protocols to disallow the reade
Gray, Eric wrote:
Stewart,
While an interesting turn of phrase, "hair shirt approach"
is hardly an accurate analogy, nor is it particularly apt to compare
presentation materials (where there's a real live person in front
of you to answer questions) with specifications (where there usual
Yaakov Stein wrote:
I created a random svg file with Inkscape, a cross-platform svg
drawing app. I created an
element with src="pretty.svg"; it displayed inline in the
cross-platform xxe XML editor using my xml2rfc
plugin (but no inline editing of the graphic) and converte
Brian E Carpenter wrote:
Speaking for myself, I agree. The whole point of rough consensus is to
leave scope for some nay-sayers, but it's for the WG Chairs (if relevant)
and the IESG to judge whether the number of objections is significant.
That is what were asking for in this case.
Stewart
Brian E Carpenter wrote:
Harald Tveit Alvestrand wrote:
--On mandag, januar 02, 2006 18:10:15 +0200 Yaakov Stein
<[EMAIL PROTECTED]> wrote:
The only thing I am sure about is
that
consensus on this list is for keeping everything exactly as it is.
I'm pretty sure there's no such consen
Ken Raeburn wrote:
On Jan 5, 2006, at 09:25, Ash, Gerald R ((Jerry)) wrote:
I'd suggest we try to reach consensus first on the following:
Alternative format(s) for IDs, in addition to ASCII text, should be
allowed.
One requirement/motivation for this change (as set forth in the ID)
is to
John C Klensin wrote:
--On Thursday, 05 January, 2006 08:25 -0600 "Ash, Gerald R
\\(Jerry\\)" <[EMAIL PROTECTED]> wrote:
Happy New Year to all!
Many thanks to Yaakov for his excellent handling of the list
discussion. I'm not very surprised with the way it has gone.
Déjà vu all
Gray, Eric wrote:
Brian,
I think it is somewhat unfair to say that we have
not tried the steps you outline below. Where we run into
trouble is when different sets of people disagree as to
which of the steps we are currently working on.
Quite frankly, I believe we can address
Eliot Lear wrote:
I agree. As usual we seem to be stuck in an infinite loop on this
mailing list with the cycle being somewhere between 6 months and 3 years.
The fact that we keep coming back to this topic may be a message in
itself!
- Stewart
Eliot
Gray, Eric wrote:
Bri
Randy.Dunlap wrote:
On Fri, 6 Jan 2006, Gray, Eric wrote:
--> "I think we have reached substantial agreement on the following
--> statement: ASCII text was good enough for my Grandfather, and it's
--> going to be good enough for my grandchildren. Please reply to this
--> CfC
Sam Hartman wrote:
"Stewart" == Stewart Bryant <[EMAIL PROTECTED]> writes:
Stewart> I am in favour of any practical method that allows us to
Stewart> progress towards the best tools for the job.
Stewart> My personal end-goal is simple: I want us
I think these are valuable inputs as well. There are people involved;
whether these people are happy, whether they will continue to work,
are important factors. Of course there are religious arguments on the
other side: "I want my architectural diagrams; they work well in the
ITU and I want th
Bob Braden wrote:
*>
*> Normative figures perhaps. Normative equations definitely.
Scott,
How about Sections 4.2.3.3 and 4.2.3.4 of RFC 1122 (1889), for examples
of readable equations in ASCII? I my experience, normative protocol
technical specifications rarely need equations much more co
Sam Hartman wrote:
Hi. With the exception of packet diagrams, I think all the examples
you bring up benefit significantly from clear textual description.
Sam
I am not saying that clear text is not needed to accompany a diagram.
However a diagram allows a lot less text to be written producing
Dassa wrote:
|> -Original Message-
|> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
|> On Behalf Of Stewart Bryant
|> Sent: Tuesday, January 10, 2006 6:47 AM
|> To: Sam Hartman
|> Cc: Harald Tveit Alvestrand; ietf@ietf.org
|> Subject: Re: Normative figures
|&g
aking some (potentially non-obvious) assumptions, right?
--> -Original Message-
--> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
--> On Behalf Of Stewart Bryant
--> Sent: Monday, January 09, 2006 2:47 PM
--> To: Sam Hartman
--> Cc: Harald Tveit Alvestrand; ietf@ietf.or
We write specifications so that they are easier to read, validate
and understand, not so that they are easier to write.
Eric
We write specs so that they will be correctly implemented.
Anything that makes a specification easier to correctly understand
surely makes it more likely that it w
Yes. And, if we're talking about wanting to make the figures
normative, I assume we are talking about a specification. In
that case, it is far more important that the description MUST
be precise, than it is that it MAY be convenient.
Please can we clarify the existing rules:
For a stan
Bob Braden wrote:
*> The draft has expired so I need to point to an external version. This draft
*> which is looking at the properties of a routing network under conditions of
*> failure would have been much clearer if it could have used mathematical
*> notation rather than ASCIIised equati
Lars-Erik Jonsson (LU/EAB) wrote:
Before I go on, I continue to be fascinated by the observation
that, each time the "we really need pictures and fancy
formatting and need them frequently" argument comes up, the vast
majority of those who make it most strongly are people whose
contributions to t
> I believe that it's appropriate for the confirming bodies to ask for
> additional information if they have reason to doubt that due proces
> has been followed or that some of the proposed appointees are suitable.
Isn't one of the roles of the liaisons to ensure that due process is
followed to t
Adrian Farrel wrote:
> Good point Jari,
>
> Can I also remind you to check in the RFC Errata pages to make sure you pick
> up any errors that have been flagged since RFC publication.
>
>
>
Of course you mean the *relevant* errata - the RFC Erratas page is so
full of junk these days that it is
Beginning
Stewart
[EMAIL PROTECTED] wrote:
> Question: Is the accomplishment of this document considered to be the
> end or rather the beginning of activities on the rerouting topic ?
>
> Heiner
>
> In einer eMail vom 29.04.2008 22:35:53 Westeuropäische Normalzeit
> schreibt [EMAIL PROTECT
At least three ADs believe that the examples should be changed
I agree with them.
Use of any identifier outside the example space may cause real harm to
the owner, where that harm may range from serious harm (technical
and/or financial) to mild embarrassment.
If anyone wants to use an ide
Eric
Missing drafts
draft-shen-csi-ecc-00.txt (wg=csi)
draft-ietf-ccid4-02.txt (wg=dccp)
draft-ietf-eai-smtpext-11.txt (wg=eai)
draft-ietf-eai-utf8headers-09.txt (wg=eai)
draft-ietf-ntp-dhcpv6-ntp-opt-00.txt (wg=ntp)
draft-ietf-psamp-info-07.txt (wg=ipfix)
draft-aitken-ipfix-new-i
Another option would be to run until 1300, that's still early enough
to have lunch but it does give us a 1.5 hour extra timeslot but only
takes that 1.5 hours, not 3.5 like the 1300 - 1500 timeslot so people
with flights at 1700 or even 1600 can possibly attend.
We could maybe start earlier on
In Paris, we switched to a late dinner which was necessary in Paris
but we did this in Dallas. Was this a general decision that I missed?
I prefer dinner from 6 - 8 and a night session where the local customs
support this. This might also cut down the need for afternoon sugar
consumption.
I
Robert Sayre wrote:
On 5/26/06, Geoff Huston <[EMAIL PROTECTED]> wrote:
Delving down a bit here, I suspect that, as always, the longstanding
issue
here is the actual level of 'independence" of the RFC Editor, and the
potential for a player to perform an end run around the IETF Internet
Stan
Besides the misquote of myself, the I-D has some misleading examples of
bad ASCII art. You cannot honestly prove that ASCII art is unusable
by abusing it. I spent a few minutes cleaning up the terrible example
in the I-D (Sorry, I am in Washington and don't have ready access to
it; I will forw
Lars-Erik Jonsson (LU/EAB) wrote:
Cogent arguments against? Very few people came out and
said that we need nothing beyond ASCII art.
If you ask people whether *we* need nothing more than ASCII,
I would guess most of us would not claim that, since even
if *I* have not had a single case w
As an example, this .gif extracted from the Y.1711 OAM protocol
would be quite difficult in ASCII. It would take a lot of words
to describe, which many people would then have to transcribe to
some sort of timing diagram - which then may or may not be
correct.
For those that cannot see the
The SOW says:
g. Document Format Conversions
1) Accept as input ascii text files and publish documents as ascii text
files,postscript files, and pdf files
2) Accept supplemental source files that may contain information such
as: code, formal descriptions (XML, ASN.1, etc.) graphics, data files,
Stewart Bryant wrote:
The SOW says:
g. Document Format Conversions
1) Accept as input ascii text files and publish documents as ascii text
files,postscript files, and pdf files
2) Accept supplemental source files that may contain information such
as: code, formal descriptions (XML, ASN.1, etc
Brian E Carpenter wrote:
The SOW will be aligned with the final version
of draft-mankin-pub-req, whose text has been adjusted
for this point in version 10.
I just greped v10 and there is no reference to pdf, nor to ps,
nor to RFC2223.
The text in section 3.9 in V10 seems ambiguous and should
First I should say that being chair of Nomcom when an innocent
mistake like this happens must be a nightmare with every possible
action being subject to criticism. Andrew therefore has a completely
thankless task in resolving this, and I will support what ever he
decides to do.
I cannot see how t
Eastlake III Donald-LDE008 wrote:
My theme here was that it is probably not humanly possible to absolutely
guarantee that no discretionary decision by the nomcom chair will ever
be required somewhere in the process of nomcom formation because it is
very hard to anticipate all possible real world
The NOMCON is by design accountable to nobody. Members cannot influence their selection in any (legitimate) way. Once appointed a NOMCON member cannot expect to be reappointed.
However the Nomcom consists of a cross-section of the community
all of whom see the same input from the community
Sam Hartman wrote:
"Jari" == Jari Arkko <[EMAIL PROTECTED]> writes:
Jari> Dave, I'm generally happy with the Nomcom process (and I
Jari> believe its a better alternative than direct voting).
Jari> However, I do agree with you that making the candidate list
Jari> publi
Ralph Droms wrote:
Perhaps we could avoid similar delays in generating the final list of
volunteers in the future:
Secretariat generates a list of eligible volunteers as early as possible
(As far as I know, eligibility data is available well before call for
volunteers is posted)
List is used
Stephane Bortzmeyer wrote:
On Wed, Jun 28, 2006 at 10:04:54AM -0400,
Henning Schulzrinne <[EMAIL PROTECTED]> wrote
a message of 48 lines which said:
Having a more formal description of state machines is a natural next
step from having, say, a good syntax description in ABNF.
Un
Stephane Bortzmeyer wrote:
On Thu, Sep 14, 2006 at 05:00:20PM +0100,
Stewart Bryant <[EMAIL PROTECTED]> wrote
a message of 56 lines which said:
Isn't there a suitable text based state description language
published by the CCITT that we can use
Pointers are welc
Generally speaking just getting the slides before the
slot is difficult enough without specifying a format
that the author may not normally use.
It is common for slides to be written at the very
last minute, and even when they are written in
advance, last minute changes that result from
discussio
Is there strong rationale for maintaining production of the CDs?
No.
IMO, free online retrieval of IETF proceedings is sufficient.
Spend the time and money on something more important.
I agree.
- Stewart
___
Ietf mailing list
Ietf@ietf.org
https
Do we have any firm evidence that we would get more work
done if we had more meetings outside the US?
Stewart
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
Scott
Historically the biggest issue with IPFIX has been that most
implementers want to run it over UDP with consequences be dammed. -
this was weaseled in the IPFIX Requirements document (RFC 3917) by
requiring (in section 6.3.1) that "For the data transfer, a congestion
aware protocol must be
Eric Burger wrote:
See http://www.sciencemag.org/cgi/reprint/318/5847/36.pdf
Which seems to be only available to those prepared to pay.
Stewart
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
What's the worst that can happen - we have to listen to the plenary
speakers without jabber sessions?
That would be pretty major!
We have had PWE3 contributors who were unable to be present in the
meeting, listen on audio and use IM for questions.
Lets do the experiment, but lets not r
Ping Pan wrote:
Exactly! It is one impressive spec: clean and simple. Looking at its
adaptation, I wonder why in the world it was not adapted and done in IETF.
On the other hand, it may take too long in IETF, and would require extensive
debate over architecture, framework, requirements... ;-)
-
Check with the lawyers, but I think that you will find that this
is strictly a US view of patents. In every other country any public
disclosure anywhere immediately voids the right to patent. Even
NDA disclosure can be tricky, because an offer for sale counts
as a disclosure.
Stewart
Doug Ro
On 01/12/2012 20:12, Stephen Farrell wrote:
Hi all,
I've just posted an idea [1] for a small process improvement.
If it doesn't seem crazy I'll try pursue it with the IESG as
an RFC 3933 process experiment. If its universally hated then
that's fine, it can die.
The IESG have seen (more-or-less)
On 02/01/2013 13:44, Carlos M. Martinez wrote:
Radio spectrum allocation was a critical task at the time (it still is,
although the world doesn't depend that much on it anymore), and one of
the task the ITU actually has performed very well, being a positive and
constructive player.
I don't know
Speaking as both a reviewer and an author, I would like
to ground this thread to some form of reality.
Can anyone point to specific cases where absence or over
use of an RFC2119 key word caused an interoperability failure,
or excessive development time?
- Stewart
We tend to think of these as state machines and describe them
accordingly. There are other approaches which might be prevented if
using a MUST when it wasn't needed.
At 10:53 AM + 1/7/13, Stewart Bryant wrote:
Speaking as both a reviewer and an author, I would like
to ground this
On 03/03/2013 14:25, Brian E Carpenter wrote:
Clearly the NomCom felt it was between a rock and a hard place; I just
want to assert the principle that balancing both managerial and technical
abilities is within NomCom's remit.
Brian
There is a subtly in the manager vs technical expert debate
Chairs
Please can you re on the question posed by Alvaro below.
Do you have any objection to adding motivation text to the draft?
Certainly I think it would be useful in IESG review.
Stewart
On 11/02/2013 21:15, Alvaro Retana (aretana) wrote:
On 1/16/13 5:17 PM, "Ben Campbell" wrote:
Ben:
A person's sex is of course only one of the recognized "protected
characteristics".
*http://www.equalityhumanrights.com/advice-and-guidance/new-equality-act-guidance/protected-characteristics-definitions/*
The full set is:
Age
Disability
Gender ressignment
Marriage and civil partnetship
Pregna
On 19/03/2013 12:59, Margaret Wasserman wrote:
On Mar 12, 2013, at 2:24 PM, Dan Harkins wrote:
I'd love to get out of this rat hole. Perhaps the signatories of the
open letter can restate the problem they see so it isn't made in terms of
race and gender.
The letter specifically mentioned the
On 20/03/2013 10:53, Margaret Wasserman wrote:
Hi Stewart,
On Mar 20, 2013, at 2:04 AM, Stewart Bryant wrote:
Age
Disability
Gender reassignment
Marriage and civil partnership
Pregnancy and maternity
Race
Religion and belief
Sex
Sexual orientation
The U.S. has a similar (although not
David
In this particular case the candidate pool would have been tiny,
because the criteria would surely have included being experienced
with both the ITU process and the IETF liaison process, including
knowing and understanding the liaison history. Therefore it
seems unlikely that there would be
On 11/02/2013 23:45, Richard Barnes wrote:
I have been selected as the General Area Review Team (Gen-ART) reviewer for
this draft (for background on Gen-ART,
pleaseseehttp://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
Please wait for direction from your document shepherd or AD before pos
Resending due to Richards change of address.
Stewart
On 11/02/2013 23:45, Richard Barnes wrote:
I have been selected as the General Area Review Team (Gen-ART) reviewer for
this draft (for background on Gen-ART,
pleaseseehttp://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
Please wait for
rcumstances
the only auto config would be teh MAC addresses.
Stewart
On Tue, Apr 2, 2013 at 9:10 AM, Stewart Bryant <mailto:stbry...@cisco.com>> wrote:
Resending due to Richards change of address.
Stewart
On 11/02/2013 23:45, Richard Barnes wrote:
I
on in general terms with the
embedded routing draft cited as an example.
Thanks,
Acee
On 3/6/13 7:01 AM, "Stewart Bryant" wrote:
Chairs
Please can you re on the question posed by Alvaro below.
Do you have any objection to adding motivation text to the draft?
Certainly I think it would be
On 12/04/2013 14:17, Fred Baker (fred) wrote:
On Apr 12, 2013, at 12:13 AM, Brian E Carpenter
wrote:
Seeing randomly selected drafts as a Gen-ART reviewer, I can
say that serious defects quite often survive WG review and
sometimes survive IETF Last Call review, so the final review
by the IESG
AB
Have you considered that the key thing to remember in the
IETF is that:
"Foo is broken because of (carefully reasoned) Bar" always trumps
"Foo is OK because of who I am" ... and of course vise versa.
Thus in the IETF influence is a function of the ability to
carefully construct a well reason
On 19/04/2013 19:13, Ted Hardie wrote:
As a working group chair, when I stare out at a sea of faces looking
for a scribe, the chances of my asking someone I know produces good
minutes is much higher than my asking someone whose work I don't know.
Think about how this often works in WGs without
On 29/04/2013 01:53, Margaret Wasserman wrote:
Hi Tom,
On Apr 19, 2013, at 6:03 AM, t.p. wrote:
If we required the IETF to reflect the diversity of people who are,
e.g., IT network professionals, then the IETF would fall apart for lack
of ability.
[…]
If the ADs of the IETF have to represent
On 29/04/2013 05:05, Michael StJohns wrote:
At 08:53 PM 4/28/2013, Margaret Wasserman wrote:
The question that people are asking is why the diversity of the IETF leadership
doesn't reflect the diversity of _the IETF_.
Let's consider for a moment that this may not actually be the correct que
On 29/04/2013 06:57, Dave Crocker wrote:
On 4/28/2013 10:52 PM, Christian Huitema wrote:
Except that the IESG members select the wg chairs, which makes your
baseline stastistic suspect; it's too easy for all sorts of biasing
factors to sway the allocation of wg chair positions.
Mike actually m
On 29/04/2013 20:39, Sam Hartman wrote:
For what it's worth, I'm not finding the current discussion is providing
me useful information for making decisions. It doesn't really matter to
me whether the problem is selection of WG chairs or selection of
IAB/IESG/IAOC after WG chairs are selected. I
On 28/05/2013 15:36, Abdussalam Baryun wrote:
It is difficult to read, because I am expecting a process and find
something else,
I started to read, but got confused (stoped reading), why you are
titling it as creating WG-draft and mentioning the adoption into the
document. I understand that the
On 07/06/2013 09:23, Abdussalam Baryun wrote:
Thanks for your respond below, AB
Thank you Richard and Abdussalam for reaching agreement
on this. I regard the issue as now closed.
Regards
Stewart Bryant
(speaking as responsible Area Director)
AB
Thomas started posting these weekly reports many years
ago as a service to the community to remind us all that
posting to ietf@ietf.org contributes to the information
and work overload of the IETF community as a whole.
The numbers are a reminder to think carefully about what
you send to the
Michel Py wrote:
Jorge Amodio wrote:
Hard to believe but Morse is still in use and required
for certain classes of radio operators.
For good reasons; in difficult conditions, Morse still delivers the
message when the voice has long stopped being recognizable. Morse would
be like ASCII: def
On 20/12/2010 18:43, Donald Eastlake wrote:
Hi,
On Mon, Dec 20, 2010 at 11:42 AM, Sam Hartman wrote:
"Radia" == Radia Perlman writes:
Radia> No objections. Radia
Can I get someone to confirm that the text in the proposed sentences is
substantially true?
I think so but I'm not an IS-I
I will put a note in the tracker
Stewart
On 15/03/2011 19:52, Les Ginsberg (ginsberg) wrote:
-Original Message-
From: Ben Campbell [mailto:b...@nostrum.com]
Sent: Tuesday, March 15, 2011 12:26 PM
To: draft-ietf-isis-genapp@tools.ietf.org
Cc: General Area Review Team; The IETF
Subj
The RTG-dir review comments :
http://www.ietf.org/mail-archive/web/rtg-dir/current/msg01533.html
Should be addressed before publication.
- Stewart
On 25/05/2011 17:13, The IESG wrote:
The IESG has received a request from the Point-to-Point Protocol
Extensions WG (pppext) to consider the fol
The IESG is considering making this statement on the
processing of RFC Errata concerning RFC Metadata.
We would appreciate community feedback.
Please can we have feedback by Thursday 9th June.
Thanks
Stewart
==
Draft text for IESG Statement on RFC Metadata
Date: xx-xxx-
This IESG
Rolf
Thank you for the review
On 19/05/2011 14:24, Rolf Winter wrote:
CONTENT:
Section 3 says:
"If a flow LSE is present, it MUST be checked to determine whether it
carries a reserved label. If it is a reserved label the packet is
processed according to the rules associated with that reserv
On 12/07/2011 23:23, Joe Touch wrote:
Hi, Joel (et al.),
On 7/10/2011 7:10 AM, Joel Halpern wrote:
Joe,
THE KARP WG Chairs have reviewed your comments, in order to figure out
what the best way to address them. We would appreciate it if you could
engage in discussion of this proposal on the KARP
On 10/08/2011 19:35, Adrian Farrel wrote:
Hi Ben,
Thanks for reading.
Nits/editorial comments:
-- section 1, paragraph 4: "...with relation to the programming..."
... in relation to...
Yeah. RFC Editor note if Stewart is watching (although I'm guessing the RFC
Editor might just fix this any
On 25/08/2011 18:12, Mary Barnes wrote:
I am also a fan of Minneapolis for meetings - the facilities at the
Hilton are perfect for our needs. There's lots of food options. It
has good air connections and there is decent pubic transport from the
airport to the city. However, this seems to be
Reviewing this discussion there are three components.
1) The update of RFC5586 to allow PW to use the GAL.
2) The PW OAM application that is to use the GAL.
3) The label stack structure when teh GAL is used with a PW
This draft is only concerned with point 1 above. Points
2 and 3 need to be re
Sasha
On 30/08/2011 13:22, Alexander Vainshtein wrote:
Stewart,
I believe that your item #1 is presumably addressed by
draft-ietf-pwe3-gal-in-pw (with the changes you’ve proposed),
draft-nadeau-pwe3-vccv-2 is an attempt to address your item #2, and
your item #3 is not yet addressed. Is th
On 01/09/2011 15:37, Yaakov Stein wrote:
Stewart
Was this email meant to address my email to the IETF discussion list
(from Tues 16 Aug)
or just the discussion on MPLS and PWE lists ?
It does to SOME extent, as it leaves open the possibility of the GAL
not being at BoS;
but it does not r
1 - 100 of 162 matches
Mail list logo
