Is this the document with the proposed SOW?
http://iaoc.ietf.org/documents/RPC-Proposed-SoW-2013-final.doc
I know that I should not this, but... I am a bit surprised
(disappointed) in seeing a proprietary format used here. I am not
saying that you should not use the Office suite to write it,
On Tue, Aug 13, 2013 at 2:00 AM, Douglas Otis doug.mtv...@gmail.com wrote:
10) Establish a reasonable fee to facilitate remote participants who
receive credit for their participation equal to that of being local.
I understand the rationale here, but I'm nervous about any movement toward
a
On 8/12/13 11:36 PM, Riccardo Bernardini wrote:
Anyway, I use Linux, so I guess I will not be able to give my input about it.
I agree in principle (MS document formats are not a suitable document
exchange format for an open standards body) but in truth, it's been
awhile since Open Office hasn't
Dave Cridland d...@cridland.net wrote:
On Tue, Aug 13, 2013 at 2:00 AM, Douglas Otis doug.mtv...@gmail.com wrote:
10) Establish a reasonable fee to facilitate remote participants who
receive credit for their participation equal to that of being local.
I understand the rationale here,
Carsten Bormann c...@tzi.org wrote:
The Concise Binary Object Representation (CBOR) is a data format
whose design goals include the possibility of extremely small code
size, fairly small message size, and extensibility without the need
for version negotiation. These design goals
Hi Murray,
At 10:36 AM 8/5/2013, Murray S. Kucherawy wrote:
RDAP is far from the first protocol specification to exist across
multiple RFCs, so this approach isn't uncommon. That said, I take
it you believe the material here should be rolled into one of the
other documents?
Yes.
Correct,
Hi Vinayak,
At 06:09 AM 8/12/2013, Vinayak Hegde wrote:
There has been a lot of discussion on the IETF mailing list regarding
improving remote participation and improving diversity on the mailing
lists and in the working groups. I think the two are related. I think
everyone broadly agrees that
On Aug 13, 2013, at 3:49 AM, Melinda Shore melinda.sh...@gmail.com wrote:
I agree in principle (MS document formats are not a suitable document
exchange format for an open standards body) but in truth, it's been
awhile since Open Office hasn't been able to read .doc files correctly.
I wonder,
http://iaoc.ietf.org/documents/RPC-Proposed-SoW-2013-final.doc
I know that I should not this, but... I am a bit surprised
(disappointed) in seeing a proprietary format used here. I am not
saying that you should not use the Office suite to write it, but you
could convert it to PDF (better,
On Tue, Aug 13, 2013 at 3:51 PM, John Levine jo...@taugh.com wrote:
http://iaoc.ietf.org/documents/RPC-Proposed-SoW-2013-final.doc
I know that I should not this, but... I am a bit surprised
(disappointed) in seeing a proprietary format used here. I am not
saying that you should not use the
On Aug 13, 2013, at 13:14, Tony Finch d...@dotat.at wrote:
Type tags don't really need to
be part of the serialization format: they can be encoded in a simpler
format by the application.
Yes, and we also can get rid of maps {a: 1, b: 2}.
Just represent them as arrays of two-element arrays
From: The IESG iesg-secret...@ietf.org
To: IETF-Announce ietf-annou...@ietf.org
Reply-To: ietf@ietf.org
Sender: iesg-secret...@ietf.org
Subject: Last Call: draft-nandakumar-rtcweb-stun-uri-05.txt (URI Scheme for
Session Traversal Utilities for NAT (STUN) Protocol) to Proposed Standard
The IESG
On Aug 13, 2013, at 9:51 AM, John Levine jo...@taugh.com wrote:
There's no great way
to send around a redlined document and I'd say that Word formats are
currently the least bad.
rfcdiff does really nicely, actually.
From: The IESG iesg-secret...@ietf.org
To: IETF-Announce ietf-annou...@ietf.org
Reply-to: iesg-secret...@ietf.org
Subject: Last Call: draft-petithuguenin-behave-turn-uris-05.txt (Traversal
Using Relays around NAT (TURN) Uniform Resource Identifiers) to Proposed
X-C5I-RSN: 1/0/934/11413/12177
On Aug 13, 2013, at 4:14 AM, Tony Finch d...@dotat.at wrote:
Carsten Bormann c...@tzi.org wrote:
The Concise Binary Object Representation (CBOR) is a data format
whose design goals include the possibility of extremely small code
size, fairly small message size, and extensibility
--On Tuesday, August 13, 2013 06:24 -0400 John Leslie
j...@jlc.net wrote:
Dave Cridland d...@cridland.net wrote:
On Tue, Aug 13, 2013 at 2:00 AM, Douglas Otis
doug.mtv...@gmail.com wrote:
10) Establish a reasonable fee to facilitate remote
participants who receive credit for their
Riccardo
All of the DOC files are in the process of being replaced with PDF files.
I apologize for the inconvenience and angst this caused.
Ray
On Aug 13, 2013, at 3:36 AM, Riccardo Bernardini wrote:
Is this the document with the proposed SOW?
I wonder, though, if this document might have contained change bars that
nobody but people who use MS
Word would see. Opening the document up in Preview on the Mac, it's just
four or five pages of
text, with no way to evaluate what changed.
It looks fine in OpenOffice. Really.
I agree with
Thank you for your review, David. The Gen-ART reviews are important feedback
for me to understand where I should look more closely.
In this case your review caused me to read the draft in detail, and I now have
similar question as you did. I have raised a Discuss in my IESG ballot so that
we
At 15:14 12-08-2013, Graham Klyne wrote:
But, in a personal capacity, not as designated reviewer, I have to
ask *why* this needs to be a URI. As far as I can tell, it is
intended for use only in very constrained environments, where there
seems to be little value in having an identifier that
At 09:25 10-08-2013, Ted Lemon wrote:
Fair point. RFC2026 does not in fact make the distinction I made.
Here is what RFC 2026 says about proposed standards:
A Proposed Standard specification is generally stable, has resolved
known design choices, is believed to be well-understood, has
On 8/13/2013 12:40 PM, SM wrote:
There is a bug in the above. I prefer to avoid quoting RFC 2026
nowadays as nobody really knows what RFC 2026; or to say it differently,
the consensus is that there isn't any consensus about RFC 2026.
Either you are wrong or we have no stable, written
Dear authors,
sorry I'm submitting these comments after the end of the LC period. I
hope they can still be of use.
- The document is well written and very clearly explained.
- I am still of the opinion that this document should better be
published as Experimental RFC. Unlike TCP and UDP. But
(leaving a full response to the authors, and responding to a couple of
points I found interesting)
On 8/13/13 3:11 PM, Yaron Sheffer yaronf.i...@gmail.com wrote:
- Arrays are prefixed by the number of elements but not by their length
in bytes. And elements need not be all of the same size. So
Ok. I assume this should be for FT? Or just something to get started?
Steve
-Original Message-
From: rfc-edi...@rfc-editor.org [rfc-edi...@rfc-editor.org]
Received: Tuesday, 13 Aug 2013, 18:18
To: ietf-annou...@ietf.org [ietf-annou...@ietf.org]; rfc-d...@rfc-editor.org
On Aug 13, 2013, at 2:11 PM, Yaron Sheffer yaronf.i...@gmail.com wrote:
sorry I'm submitting these comments after the end of the LC period. I hope
they can still be of use.
No problem, and the are. Some answers below.
- The diagnostic notation can be used very effectively for things like
Hi -
From: Yaron Sheffer yaronf.i...@gmail.com
Sent: Aug 13, 2013 2:11 PM
To: IETF Discussion Mailing List ietf@ietf.org
Subject: re: Last Call: draft-bormann-cbor-04.txt (Concise Binary Object
Representation (CBOR)) to Proposed Standard
...
- The diagnostic notation can be used very
The IESG has received a request from the Diameter Maintenance and
Extensions WG (dime) to consider the following document:
- 'Realm-Based Redirection In Diameter'
draft-ietf-dime-realm-based-redirect-11.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 6980
Title: Security Implications of IPv6 Fragmentation
with IPv6 Neighbor Discovery
Author: F. Gont
Status: Standards Track
Stream:
29 matches
Mail list logo
