On 05/03/2012 19:40, Barry Leiba wrote:
2. I, too, noticed all the lower-case should and may words. I
suggest that the best way to handle this is to make the following
change to the RFC 2119 citation text at the beginning of section 2:
NEW
The key words MUST, MUST NOT, REQUIRED, SHALL,
On 05/03/2012 18:00, Murray S. Kucherawy wrote:
-Original Message-
From: Alexey Melnikov [mailto:alexey.melni...@isode.com]
Sent: Monday, March 05, 2012 4:00 AM
To: Murray S. Kucherawy
Cc:ietf@ietf.org
Subject: Re: Last Call:draft-melnikov-smtp-priority-07.txt (Simple
Mail Transfer
Hi Ned,
On 05/03/2012 15:34, Ned Freed wrote:
That said, I think an important omission in this document is that it
only allows MSA's to change message priorities to conform to site
policy.
MTAs should also be allowed to do this.
Can you elaborate a bit more on possible use cases?
I am finding myself with some unfamiliar bedfellows on this issue, but yes, it
should be approved - see inline.
Tom Petch
- Original Message -
From: John C Klensin john-i...@jck.com
To: stbry...@cisco.com
Cc: ietf@ietf.org
Sent: Friday, March 02, 2012 12:04 AM
Subject: Re: Last
Hi,
I speak now as an individual and in no other capacity with no other hats on.
On 3/6/12 11:31 AM, t.petch wrote:
I am finding myself with some unfamiliar bedfellows on this issue, but yes, it
should be approved - see inline.
We claim ownership of the name space on behalf of all parties,
Mark Andrews ma...@isc.org wrote:
I would say DNS master file representation - DNS wire representation
is one of the main issues on the provisioning side. This conversion
needs to be done at some point.
John's draft addresses that.
The other this is verification of the input.
What kind of
As a subscriber of the i-d-annou...@ietf.org list, I generally prefer
reading the HTML version of the draft rather than the TXT version.
I thus often need to manually rewrite the TXT link to fetch the HTML
version of the draft. I can not believe I'm the only one.
Hence, would it be possible to
On 2012-03-06 14:41, Xavier Marjou wrote:
As a subscriber of the i-d-annou...@ietf.org list, I generally prefer
reading the HTML version of the draft rather than the TXT version.
I thus often need to manually rewrite the TXT link to fetch the HTML
version of the draft. I can not believe I'm the
On 2012-03-06 08:51, Julian Reschke wrote:
On 2012-03-06 14:41, Xavier Marjou wrote:
As a subscriber of the i-d-annou...@ietf.org list, I generally prefer
reading the HTML version of the draft rather than the TXT version.
I thus often need to manually rewrite the TXT link to fetch the HTML
Even better, also add the XML2RFC output if it's available at the same time:
http://tools.ietf.org/id/draft-name.html
for example, (just picking my own latest draft as an example):
http://tools.ietf.org/id/draft-nir-websec-extended-origin-02.html
I don't know which drafts get this version
On Tue, Mar 6, 2012 at 2:53 PM, Simon Perreault
simon.perrea...@viagenie.ca wrote:
On 2012-03-06 08:51, Julian Reschke wrote:
On 2012-03-06 14:41, Xavier Marjou wrote:
As a subscriber of the i-d-annou...@ietf.org list, I generally prefer
reading the HTML version of the draft rather than the
On 2012-03-06 14:56, Yoav Nir wrote:
Even better, also add the XML2RFC output if it's available at the same time:
http://tools.ietf.org/id/draft-name.html
for example, (just picking my own latest draft as an example):
http://tools.ietf.org/id/draft-nir-websec-extended-origin-02.html
+1
I
+1. This will save a few typing and clicks.
Xavier Marjou wrote:
As a subscriber of the i-d-annou...@ietf.org list, I generally prefer
reading the HTML version of the draft rather than the TXT version.
I thus often need to manually rewrite the TXT link to fetch the HTML
version of the draft.
I would be much happier with a link to the datatracker HTML version:
https://datatracker.ietf.org/doc/draft-name/
Would this meet your needs?
Russ
On Mar 6, 2012, at 8:41 AM, Xavier Marjou wrote:
As a subscriber of the i-d-annou...@ietf.org list, I generally prefer
reading the HTML version
I would be much happier with a link to the datatracker HTML version:
https://datatracker.ietf.org/doc/draft-name/
Would this meet your needs?
then we can each have our cake and eat it too. but i fear folk may just
want the bright shiny.
randy
___
On 3/6/2012 6:12 AM, Russ Housley wrote:
I would be much happier with a link to the datatracker HTML version:
https://datatracker.ietf.org/doc/draft-name/
+1
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
Ietf mailing list
In message alpine.lsu.2.00.1203061314260.22...@hermes-2.csi.cam.ac.uk, Tony F
inch writes:
Mark Andrews ma...@isc.org wrote:
I would say DNS master file representation - DNS wire representation
is one of the main issues on the provisioning side. This conversion
needs to be done at some
Is the following better:
tThe Importance xref target=RFC2156/ header field MUST NOT be used for
determining
the priority under this Priority Message Handling SMTP extension.
In absence of both the PRIORITY MAIL FROM parameter and the MT-Priority
header field,
other message
On Tue, Mar 6, 2012 at 3:24 PM, Randy Bush ra...@psg.com wrote:
I would be much happier with a link to the datatracker HTML version:
https://datatracker.ietf.org/doc/draft-name/
Would this meet your needs?
Yes, it would be fine. From my point of view the two versions are
almost equivalent,
It would be acceptable to me, especially since there's a link from there
to the tools HTML version. (Look for the html link at the top.)
Tony Hansen
On 3/6/2012 9:12 AM, Russ Housley wrote:
I would be much happier with a link to the datatracker HTML version:
Input -P- DNS server -D- DNS stub -Q- Output
P is the provisioning
I think you want to break that into the provisioning interface and the data
format it produces that the DNS server consumes. (My reason for that is we have
a specification for at least such format, with all that implies.)
I
With a link like https://datatracker.ietf.org/doc/draft-name/ (e.g.
https://datatracker.ietf.org/doc/draft-nir-websec-extended-origin/ ),
I will most often then click again on the html top right link. But I'm
fine with it too.
On Tue, Mar 6, 2012 at 3:12 PM, Russ Housley hous...@vigilsec.com
The XML2RFC version is not linked from there. If that was added to the Other
versions field, that would be great.
On Mar 6, 2012, at 5:11 PM, Xavier Marjou wrote:
With a link like https://datatracker.ietf.org/doc/draft-name/ (e.g.
Input -P- DNS server -D- DNS stub -Q- Output
P is the provisioning
I think you want to break that into the provisioning interface and the data
format it produces that the DNS server consumes. (My reason for that is we
have
a specification for at least such format, with all that implies.)
On Mar 6, 2012, at 8:41 AM, Xavier Marjou wrote:
As a subscriber of the i-d-annou...@ietf.org list, I generally prefer
reading the HTML version of the draft rather than the TXT version.
I thus often need to manually rewrite the TXT link to fetch the HTML
version of the draft. I can not
On 06/Mar/12 04:56, ned+i...@mauve.mrochek.com wrote:
On 05/Mar/12 18:09, John Levine wrote:
Would you really want to build an SPF or DKIM parser into every
DNS server? That's a lot of code that the DNS manager doesn't
care about, but the mail manager does.
But it would be the same code,
- Original Message -
From: Eliot Lear l...@cisco.com
To: t.petch daedu...@btconnect.com
Cc: John C Klensin john-i...@jck.com; stbry...@cisco.com; ietf@ietf.org
Sent: Tuesday, March 06, 2012 12:46 PM
Hi,
I speak now as an individual and in no other capacity with no other hats on.
On
On 3/3/12 7:07 PM, ned+i...@mauve.mrochek.com wrote:
This draft also defines the MT-Priority header field. �It is quite unusual
for a SMTP extension specification to define a mail header field. ...
This is my major concern about this protocol as well, as I note in the
PROTO writeup (which,
John R. Levine jo...@iecc.com wrote:
I was also going to mention that. There's a lot of different formats for zone
file data, with BIND-ish master files being only one of them.
DNS master files are specified in RFC 1035 so it's wrong to imply they are
implementation-specific.
Tony.
--
I was also going to mention that. There's a lot of different formats for zone
file data, with BIND-ish master files being only one of them.
DNS master files are specified in RFC 1035 so it's wrong to imply they are
implementation-specific.
They're not implementation specific, but they're
-Original Message-
From: Alberto García [mailto:albe...@it.uc3m.es]
Sent: Tuesday, March 06, 2012 9:07 AM
To: 'Dan Wing'; 'IETF discussion list'
Cc: 'Transport Directorate'; tsv-a...@ietf.org; joe.ab...@icann.org;
'marcelo bagnulo braun'
Subject: RE: tsv-dir review of
On 06/Mar/12 16:00, John R. Levine wrote:
We seem to believe that the D part is deployed so that adding new
unknown RRTypes is not an issue.
I think this is correct, but OTOH someone recently asked about
possible issues in this area, and if I remember correctly,
received no response.
On Tuesday, March 06, 2012 06:34:58 PM Alessandro Vesely wrote:
On 06/Mar/12 16:00, John R. Levine wrote:
We seem to believe that the D part is deployed so that adding new
unknown RRTypes is not an issue.
I think this is correct, but OTOH someone recently asked about
possible issues in
almost equivalent, this latter maybe is more flexible (at the expense
of one more click, which is negligible)
Re: one more click...
https://datatracker.ietf.org/cookies/
Note the third item.
Barry
___
Ietf mailing list
Ietf@ietf.org
Folks, we've issued a second Last Call on this document because based on
IESG feedback the intended status has changed from Informational to
Proposed Standard.
On 3/6/12 10:45 AM, The IESG wrote:
The IESG has received a request from an individual submitter to consider
the following document:
A new IETF working group has been proposed in the Real-Time Applications
and Infrastructure Area.
...
INtermediary-safe SIP session ID (insipid)
I think the working group is a good idea, and I think the charter is
fine. Charter away.
Just a very, very small point:
There's some value in being
-Original Message-
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of
Xavier Marjou
Sent: Tuesday, March 06, 2012 5:42 AM
To: IETF Discussion
Subject: Add a link to the HTML version in i-d-announce mails ?
As a subscriber of the i-d-annou...@ietf.org list, I
-Original Message-
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Russ
Housley
Sent: Tuesday, March 06, 2012 6:13 AM
To: Xavier Marjou
Cc: IETF Discussion
Subject: Re: Add a link to the HTML version in i-d-announce mails ?
I would be much happier with a
Hi Dan,
Thank you very much for your review
| -Mensaje original-
| De: Dan Wing [mailto:dw...@cisco.com]
| Enviado el: jueves, 01 de marzo de 2012 3:56
| Para: 'IETF discussion list'
| CC: 'Transport Directorate'; tsv-a...@ietf.org; joe.ab...@icann.org;
| 'marcelo bagnulo braun';
On 2012-03-06 16:26, Yoav Nir wrote:
The XML2RFC version is not linked from there. If that was added to the Other
versions field, that would be great.
...
Indeed. HTMLized plain text is progress over plain text, but properly
generated HTML is better.
But I fear we're getting close to our
On Mar 6, 2012, at 11:44 PM, Julian Reschke wrote:
On 2012-03-06 16:26, Yoav Nir wrote:
The XML2RFC version is not linked from there. If that was added to the
Other versions field, that would be great.
...
Indeed. HTMLized plain text is progress over plain text, but properly
generated
In message alpine.bsf.2.00.1203061203020.14...@joyce.lan, John R. Levine wr
ites:
I was also going to mention that. There's a lot of different formats for
zone
file data, with BIND-ish master files being only one of them.
DNS master files are specified in RFC 1035 so it's wrong to
Pictures in RFCs?
Come to the RFCFORM BOF to voice opinions on this topic.
Russ
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
They're not implementation specific, but they're also not required to
interoperate, as the wire format queries and responses are.
They are a interchange standard as per RFC 1034.
Yes, we all know that. But as I presume you also know, there are plenty
of DNS servers that store the zone info
On 3/1/12 5:14 PM, Scott Kitterman wrote:
Peter Saint-Andre stpe...@stpeter.im wrote:
On 3/1/12 12:00 PM, Scott Kitterman wrote:
On Thursday, March 01, 2012 10:47:50 AM The IESG wrote:
The IESG has received a request from the Applications Area Working
Group
WG (appsawg) to consider the
In message 4f564ac2.1040...@tana.it, Alessandro Vesely writes:
On 06/Mar/12 16:00, John R. Levine wrote:
We seem to believe that the D part is deployed so that adding new
unknown RRTypes is not an issue.
I think this is correct, but OTOH someone recently asked about
possible issues
On Tuesday, March 06, 2012 03:19:41 PM Peter Saint-Andre wrote:
On 3/1/12 5:14 PM, Scott Kitterman wrote:
Peter Saint-Andre stpe...@stpeter.im wrote:
On 3/1/12 12:00 PM, Scott Kitterman wrote:
On Thursday, March 01, 2012 10:47:50 AM The IESG wrote:
The IESG has received a request from the
On 3/6/12 3:24 PM, Scott Kitterman wrote:
On Tuesday, March 06, 2012 03:19:41 PM Peter Saint-Andre wrote:
On 3/1/12 5:14 PM, Scott Kitterman wrote:
Peter Saint-Andre stpe...@stpeter.im wrote:
On 3/1/12 12:00 PM, Scott Kitterman wrote:
On Thursday, March 01, 2012 10:47:50 AM The IESG wrote:
On Tuesday, March 06, 2012 03:30:44 PM Peter Saint-Andre wrote:
On 3/6/12 3:24 PM, Scott Kitterman wrote:
On Tuesday, March 06, 2012 03:19:41 PM Peter Saint-Andre wrote:
On 3/1/12 5:14 PM, Scott Kitterman wrote:
Peter Saint-Andre stpe...@stpeter.im wrote:
On 3/1/12 12:00 PM, Scott
At 3:30 PM -0700 3/6/12, Peter Saint-Andre wrote:
In my working copy I've changed that paragraph to:
Implementations of application protocols MUST NOT programatically
discriminate between standard and non-standard parameters based
solely on the names of such parameters (i.e.,
Not that voicing opinions on this topic has ever done any good. -T
On Tue, Mar 6, 2012 at 2:15 PM, Russ Housley hous...@vigilsec.com wrote:
Pictures in RFCs?
Come to the RFCFORM BOF to voice opinions on this topic.
Russ
___
Ietf mailing list
On 3/6/12 4:19 PM, Randall Gellens wrote:
At 3:30 PM -0700 3/6/12, Peter Saint-Andre wrote:
In my working copy I've changed that paragraph to:
Implementations of application protocols MUST NOT programatically
discriminate between standard and non-standard parameters based
On 3/2/12 5:48 PM, Randall Gellens wrote:
Hi all,
Hi Randall, thank you for the review and suggested text.
Three suggestions for edits:
First: I suggest adding a brief note to this text in Appendix B:
2. When parameter names might have significant meaning. However,
this case
Hey Peter,
-Original Message-
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Peter
Saint-Andre
Sent: Tuesday, March 06, 2012 3:32 PM
To: Randall Gellens
Cc: Mark Nottingham; ietf@ietf.org
Subject: Re: Last Call: draft-ietf-appsawg-xdash-03.txt (Deprecating
On 3/6/12 4:46 PM, Murray S. Kucherawy wrote:
Hey Peter,
Howdy. :)
-Original Message-
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of
Peter Saint-Andre
Sent: Tuesday, March 06, 2012 3:32 PM
To: Randall Gellens
Cc: Mark Nottingham; ietf@ietf.org
Subject:
At 4:32 PM -0700 3/6/12, Peter Saint-Andre wrote:
On 3/6/12 4:19 PM, Randall Gellens wrote:
At 3:30 PM -0700 3/6/12, Peter Saint-Andre wrote:
In my working copy I've changed that paragraph to:
Implementations of application protocols MUST NOT programatically
discriminate
Last month I ran into a guy on the dmarc list who complained that his
server returns NOTIMP in response to queries for SPF records (because
it doesn't implement them) and clients were doing odd things. But
it's been a long time since I've run into anyone else like that, so I
agree, it's
Hi Peter,
At 4:42 PM -0700 3/6/12, Peter Saint-Andre wrote:
On 3/2/12 5:48 PM, Randall Gellens wrote:
Hi all,
Hi Randall, thank you for the review and suggested text.
Three suggestions for edits:
First: I suggest adding a brief note to this text in Appendix B:
2. When
Yup, you are not the only one -- this annoyed me sufficiently that I finally
gave
in and wrote a Chrome extension to do this for me.
Basically it watches the address bard and looks for www.ietf.org/id/foo and,
depending on the setting in the options page, will redirect to the Tools or
it would be a very broken implementation, but not something
that harmed the Internet or even anyone else whose applications worked
properly. At most it would harm its own user, who I assume would quickly
dump it.
I don't think harm to the Internet is the bar for MUST. If your
implementation
At 7:53 PM -0500 3/6/12, Barry Leiba wrote:
it would be a very broken implementation, but not something
that harmed the Internet or even anyone else whose applications worked
properly. At most it would harm its own user, who I assume would quickly
dump it.
I don't think harm to the
On Mar 6, 2012, at 7:43 PM, Barry Leiba wrote:
Yup, you are not the only one -- this annoyed me sufficiently that I finally
gave
in and wrote a Chrome extension to do this for me.
Basically it watches the address bard and looks for www.ietf.org/id/foo
and,
depending on the setting in the
On 07/03/2012, at 10:32 AM, Peter Saint-Andre wrote:
On 3/6/12 4:19 PM, Randall Gellens wrote:
At 3:30 PM -0700 3/6/12, Peter Saint-Andre wrote:
In my working copy I've changed that paragraph to:
Implementations of application protocols MUST NOT programatically
discriminate
At 1:02 PM +1100 3/7/12, Mark Nottingham wrote:
On 07/03/2012, at 10:32 AM, Peter Saint-Andre wrote:
On 3/6/12 4:19 PM, Randall Gellens wrote:
At 3:30 PM -0700 3/6/12, Peter Saint-Andre wrote:
In my working copy I've changed that paragraph to:
Implementations of application
In message alpine.bsf.2.00.1203061711470.25...@joyce.lan, John R. Levine wr
ites:
They're not implementation specific, but they're also not required to
interoperate, as the wire format queries and responses are.
They are a interchange standard as per RFC 1034.
Yes, we all know that.
However we do have standard presentation/entry formats defined and a good
front end will accept those as well.
Sigh. Now we're back to people who don't do it my way are wrong, so I
guess we're done.
Regards,
John Levine, jo...@iecc.com, Primary Perpetrator of The Internet for Dummies,
On 07/03/2012, at 1:34 PM, Randall Gellens wrote:
At 1:02 PM +1100 3/7/12, Mark Nottingham wrote:
On 07/03/2012, at 10:32 AM, Peter Saint-Andre wrote:
On 3/6/12 4:19 PM, Randall Gellens wrote:
At 3:30 PM -0700 3/6/12, Peter Saint-Andre wrote:
In my working copy I've changed that
To me, the target of that language is software that generically treats
protocol elements beginning with x- in a fundamentally different
way, without knowledge of its semantics. That is broken, causes real
harm, and I have seen it deployed.
clue bat please? is there any general semantic to
In message 20120307000814.29422.qm...@joyce.lan, John Levine writes:
Last month I ran into a guy on the dmarc list who complained that his
server returns NOTIMP in response to queries for SPF records (because
it doesn't implement them) and clients were doing odd things. But
it's been
Last month I ran into a guy on the dmarc list who complained that his
server returns NOTIMP in response to queries for SPF records (because
it doesn't implement them) and clients were doing odd things. But
it's been a long time since I've run into anyone else like that, so I
agree, it's not an
On 07/03/2012, at 1:52 PM, Randy Bush wrote:
To me, the target of that language is software that generically treats
protocol elements beginning with x- in a fundamentally different
way, without knowledge of its semantics. That is broken, causes real
harm, and I have seen it deployed.
clue
In message alpine.bsf.2.00.1203062148410.34...@joyce.lan, John R. Levine wr
ites:
However we do have standard presentation/entry formats defined and a good
front end will accept those as well.
Sigh. Now we're back to people who don't do it my way are wrong, so I
guess we're done.
One
One of point of having standard presentation formats is that they
facilitate data interchange.
bind's zone format is not a standard, and many implementations are not
compatible with it. get over it.
randy
___
Ietf mailing list
Ietf@ietf.org
In message m2obs9f3bj.wl%ra...@psg.com, Randy Bush writes:
One of point of having standard presentation formats is that they
facilitate data interchange.
bind's zone format is not a standard, and many implementations are not
compatible with it. get over it.
Actually it is STD 13. Get
Mark Andrews wrote:
John Levine writes:
In case it wasn't clear, this is an authoritative server.
If this is about permitted RCODEs here
http://tools.ietf.org/html/rfc1035#section-4.1.1
then an RCODE of 4 in the response looks like a perfectly valid response
for a DNS Server to a
But it does clue one in immediately to the fact that the parameter is
non-standard.
Paul
-Original Message-
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of
Mark Nottingham
Sent: Tuesday, March 06, 2012 11:11 PM
To: Randy Bush
Cc: Randall Gellens;
Yes, but (as the draft tries to explain) putting this kind of metadata in a
name is prone to issues, because it can change -- i.e., when a header (or other
protocol element) becomes standard.
On 07/03/2012, at 4:54 PM, Paul E. Jones wrote:
But it does clue one in immediately to the fact
In message 201203070539.q275dmj8001...@fs4113.wdf.sap.corp, Martin Rex writes
:
Mark Andrews wrote:
John Levine writes:
In case it wasn't clear, this is an authoritative server.
If this is about permitted RCODEs here
http://tools.ietf.org/html/rfc1035#section-4.1.1
then an
I suppose one could argue that X- should never be on the Public Internet,
anyway. But they are. If we remove X-, then what will happen is developers
will use names that don't have X-. Will that make things better? No. I'd
argue it will make it worse.
Non-standard extensions do present
At 1:19 AM -0500 3/7/12, Paul E. Jones wrote:
I suppose one could argue that X- should never be on the Public Internet,
anyway. But they are. If we remove X-, then what will happen is developers
will use names that don't have X-. Will that make things better? No. I'd
argue it will make
On 7 mar 2012, at 03:49, John R. Levine wrote:
However we do have standard presentation/entry formats defined and a good
front end will accept those as well.
Sigh. Now we're back to people who don't do it my way are wrong, so I
guess we're done.
I disagree.
People who don't accept the
In message d468354f-be26-41d4-9f75-ea10c5189...@frobbit.se, =?iso-8859-1?Q?Pa
trik_F=E4ltstr=F6m?= writes:
On 7 mar 2012, at 03:49, John R. Levine wrote:
However we do have standard presentation/entry formats defined and a good
front end will accept those as well.
Sigh. Now we're
The IESG has received a request from the Source Address Validation
Improvements WG (savi) to consider the following document:
- 'SAVI Solution for DHCP'
draft-ietf-savi-dhcp-12.txt as a Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits
final comments on
Reminder: this is your last day to order the winning IETF 83 t-shirt. T-shirts
cost $15 USD and are available in a wide variety of both men's and women's
sizes. Please note that you must place your order by 11pm PT on Tuesday, March
6 in order to be guaranteed a t-shirt. We may have a limited
The IESG has received a request from the Multicast Mobility WG (multimob)
to consider the following document:
- 'Tuning the Behavior of IGMP and MLD for Routers in Mobile and Wireless
Networks'
draft-ietf-multimob-igmp-mld-tuning-04.txt as an Informational RFC
The IESG plans to make a
The IESG has approved the following document:
- 'LISP Map-Versioning'
(draft-ietf-lisp-map-versioning-09.txt) as an Experimental RFC
This document is the product of the Locator/ID Separation Protocol
Working Group.
The IESG contact persons are Jari Arkko and Ralph Droms.
A URL of this
The IESG has approved the following document:
- 'Analysis of Stateful 64 Translation'
(draft-ietf-behave-64-analysis-07.txt) as an Informational RFC
This document is the product of the Behavior Engineering for Hindrance
Avoidance Working Group.
The IESG contact persons are David Harrington and
The IESG has received a request from the Benchmarking Methodology WG
(bmwg) to consider the following document:
- 'Methodology for benchmarking MPLS protection mechanisms'
draft-ietf-bmwg-protection-meth-09.txt as an Informational RFC
The IESG plans to make a decision in the next few weeks,
The IESG has received a request from an individual submitter to consider
the following document:
- 'The Atom deleted-entry Element'
draft-snell-atompub-tombstones-15.txt as a Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.
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
The Ad-Hoc Network Autoconfiguration (autoconf) working group in the Internet
Area has concluded. The IESG contact persons are Jari Arkko and Ralph Droms.
This working group has reached a successful termination point. We are very
happy with the RFC that has been produced by the working group,
The IESG has approved the following document:
- 'Interworking LISP with IPv4 and IPv6'
(draft-ietf-lisp-interworking-06.txt) as an Experimental RFC
This document is the product of the Locator/ID Separation Protocol
Working Group.
The IESG contact persons are Jari Arkko and Ralph Droms.
A URL
The IESG has approved the following document:
- 'The Canonical Link Relation'
(draft-ohye-canonical-link-relation-05.txt) as an Informational RFC
This document has been reviewed in the IETF but is not the product of an
IETF Working Group.
The IESG contact person is Peter Saint-Andre.
A URL of
The IESG has received a request from the FEC Framework WG (fecframe) to
consider the following document:
- 'Raptor FEC Schemes for FECFRAME'
draft-ietf-fecframe-raptor-10.txt as a Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this
The IESG has approved the following document:
- 'Sieve Email Filtering: Include Extension'
(draft-ietf-sieve-include-15.txt) as a Proposed Standard
This document is the product of the Sieve Mail Filtering Language Working
Group.
The IESG contact persons are Pete Resnick and Peter Saint-Andre.
95 matches
Mail list logo
