In the process of doing the apps area review, I came across some points
that were not related to applications. The basis for these comments is
precisely the sentiment that Russ Housley expressed, which is that the
specification is done when there is no more to remove. With this
document, I
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
On 11 April the IAOC announced that it was considering asking for
gender information during the IETF meeting registration process
starting with IETF 87, and asked for the community to provide feedback
by 17 April as the IAOC planned to make a decision on 18 April.
The data is being gathered to
And the technology that my team is pushing would be Saratoga:
http://saratoga.sf.net
which has interoperable implementations that can do 50Mbps in perl, a decade of
operational experience in its application domain, and mature drafts.
But this is in the transport area, and TSV has somewhat
Being a scribe can be a good way for people to know who you are (the scribe).
From reading the thread on this, when you ask someone who is new, how about
having them sit next to someone who is more familiar with the attendees to help
with names? Maybe for those which English is not a first
Earlier, Eliot Lear wrote:
% Put simply, you are over-specifying the RID
% and derive no benefit from doing so.
There is benefit to implementers in having a specific
example that is known to meet the requirements of
this specification. This benefit also accrues to users,
as implementers are
RJ == RJ Atkinson rja.li...@gmail.com writes:
RJ I oppose Eliot's proposed edits on grounds that they would
RJ reduce the clarity of the specification and also would reduce
RJ IETF and WG consensus about this specification.
Ran, I just checked, and you don't seem to be a 6man
On Mon, Apr 22, 2013 at 3:04 PM, Moriarty, Kathleen
kathleen.moria...@emc.com wrote:
Being a scribe can be a good way for people to know who you are (the
scribe). From reading the thread on this, when you ask someone who is new,
how about having them sit next to someone who is more familiar
Dear Benoit, all
I submitted v16 of the Internet Draft.
I modified section 9.1.1 on the maintenance of the flowSelectorAlgorithm
registry and fixed the editorial issue in section 6.1.1
I have also used MUST in section 6.1
Best regards,
Salvatore
Da: Benoit Claise
On Sat, Apr 20, 2013 at 12:21:52AM -0700, David Morris wrote:
On Sat, 20 Apr 2013, Mark Nottingham wrote:
p1 Section 2.3 says:
However, an HTTP-to-HTTP gateway that wishes to interoperate with
third-party HTTP servers must conform to HTTP user agent requirements
on the
On Sat, Apr 20, 2013 at 05:55:59PM +1000, Mark Nottingham wrote:
On 20/04/2013, at 5:21 PM, David Morris d...@xpasc.com wrote:
I don't care about MUST, but I think the Via header can be useful for
problem determination. A smart content server could also adjust for
a detected
Sam Hartman wrote:
RJ Atkinson rja.li...@gmail.com writes:
RJ I oppose Eliot's proposed edits on grounds that they would
RJ reduce the clarity of the specification and also would reduce
RJ IETF and WG consensus about this specification.
Ran, I just checked, and you don't
Well, there isn't a delay tolerant networks working group, but the IRTF has a
DTNRG ( http://irtf.org/dtnrg ).
At least one of the chairs is a goer. If you really wanted to standardize
this, wouldn't you be able to find 1-2 people on the DTNRG list who would be
willing to do the BoF thing?
At 09:56 AM 4/22/2013, Sam Hartman wrote:
RJ == RJ Atkinson rja.li...@gmail.com writes:
RJ I oppose Eliot's proposed edits on grounds that they would
RJ reduce the clarity of the specification and also would reduce
RJ IETF and WG consensus about this specification.
Ran, I just
On 4/19/2013 2:02 AM, Yoav Nir wrote:
Only that you know enough people so that you could push a new technology even
without attending,
IETF work officially happens on IETF lists, not at in-person meetings.
As per the Tao of the IETF: Any decision made at a face-to-face meeting
must also
Eliot,
am Mon, Apr 22, 2013 at 06:22:24PM +0200 hast du folgendes geschrieben:
I asked the above question because it is at least conceivable that at
some point host portion != 64 bits and this is the only place in the
document where the requirement is stated. Yes, screwing with the 64
bit
H Fernando,
On 4/22/13 9:23 PM, Fernando Gont wrote:
There seems to be a disconnect here:
We want an algorithm that, roughly speaking, whenever you connect to the
same network, gives you the same address. But such address should be
different for each network you connect to.
Thank you, and
Hi Fernando,
Please note that this is not an objection.
At 12:40 22-04-2013, Fernando Gont wrote:
PLease see the Appendix.
I read that. I was confused by the short title (Stable Privacy
Addresses) at first. I didn't see much discussion in the draft about
privacy considerations. For what
It did go to IETF-Announce. It's just no longer in the To: field so
people stop doing a reply-all and end up sending to it. (Basically, it's
Bcc'ed. For e-mail geeks like me: An empty group list of
IETF-Announce:; is now in the To: field.)
pr
On 4/22/13 3:39 PM, Clint Chaplin wrote:
Why did
On 11 April the IAOC announced that it was considering asking for
gender information during the IETF meeting registration process
starting with IETF 87, and asked for the community to provide feedback
by 17 April as the IAOC planned to make a decision on 18 April.
The data is being gathered to
The IESG has received a request from the NETCONF Data Modeling Language
WG (netmod) to consider the following document:
- 'A YANG Data Model for IP Management'
draft-ietf-netmod-ip-cfg-09.txt as Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits
final
The IESG has received a request from the NETCONF Data Modeling Language
WG (netmod) to consider the following document:
- 'A YANG Data Model for Interface Management'
draft-ietf-netmod-interfaces-cfg-10.txt as Proposed Standard
The IESG plans to make a decision in the next few weeks, and
The IESG has received a request from the Geographic Location/Privacy WG
(geopriv) to consider the following document:
- 'Relative Location Representation'
draft-ietf-geopriv-relative-location-04.txt as Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits
The IESG has approved the following document:
- 'A Uniform Resource Name (URN) Namespace for Examples'
(draft-saintandre-urn-example-05.txt) as Best Current Practice
This document has been reviewed in the IETF but is not the product of an
IETF Working Group.
The IESG contact person is Barry
A new Request for Comments is now available in online RFC libraries.
RFC 6920
Title: Naming Things with Hashes
Author: S. Farrell, D. Kutscher,
C. Dannewitz, B. Ohlman,
A. Keranen, P. Hallam-Baker
Status:
The IESG has received a request from the Dynamic Host Configuration WG
(dhc) to consider the following document:
- 'Reconfigure Triggered by DHCPv6 Relay Agents'
draft-ietf-dhc-triggered-reconfigure-05.txt as Proposed Standard
The IESG plans to make a decision in the next few weeks, and
A new Request for Comments is now available in online RFC libraries.
RFC 6914
Title: SIMPLE Made Simple: An Overview
of the IETF Specifications for Instant
Messaging and Presence Using the Session
The IESG has received a request from the Geographic Location/Privacy WG
(geopriv) to consider the following document:
- 'Using Device-provided Location-Related Measurements in Location
Configuration Protocols'
draft-ietf-geopriv-held-measurements-07.txt as Proposed Standard
The IESG plans
The IESG has received a request from the Benchmarking Methodology WG
(bmwg) to consider the following document:
- 'IMIX Genome: Specification of variable packet sizes for additional
testing'
draft-ietf-bmwg-imix-genome-04.txt as Informational RFC
The IESG plans to make a decision in the
29 matches
Mail list logo
