Re: draft-guo-idoca-with-the-html-file-format-00

Yes，I think this idea very goog too, But how to make various software vendors agree to do so ?Especially in larger companies ,such as google docs, office365,why they to do so ?where they do the interest in this？And finally the implementation of the technology is who is going to achieve? Susie O

Re: team to look at diversity

Jari, this is great news. A design team approach may be able to collect information and generate ideas and actionable points in a way that works much better than ranting on the IETF list. The most important insight is that diversity is not a "problem" that can be "fixed" by some set of measures,

Re: draft-guo-idoca-with-the-html-file-format-00

Dear Mr. Guo, This I-D is a good idea. It is the first time I hear about the idea of IDOCA (Interconnection and Interoperability of Cloud-Office Application) with the html file format. If this idea comes true, it will be beneficial to all cloud-office user. However, the problem of security will ar

team to look at diversity

I have an update relating to the diversity discussions we've had on the list and at IETF-86. I promised that I'd set up a design team. I have found two people to lead such a design team: Kathleen Moriarty and Suresh Krishnan. Thank you volunteering to lead this! Please contact them if you are i

Re: RFC 6921 on Design Considerations for Faster-Than-Light (FTL) Communication

The words in this message are to be interpreted as described in RFC 6919. Here are some considerations for Faster-Than-Light Communication (see RFC 6921). * Bring value when you send a message. Do not seek value. Value-seeking questions such as, "What are you doing tonight?" make peopl

Re: RFC 6921 on Design Considerations for Faster-Than-Light (FTL) Communication

Delete >The communication times don't change if at least one communicator is not > moving in light speed. AB> I meant the communication times MAY change if at least one communicator is moving in light speed. On 4/2/13, Abdussalam Baryun wrote: > RFC6921>It is well known that as we approach the

Re: RFC 6921 on Design Considerations for Faster-Than-Light (FTL) Communication

RFC6921>It is well known that as we approach the speed of light, time slows down. AB> I know that time slows for something when it is in speed of light, but communication is not something moving. If the packet is in speed of light we may reduce the comm-delay but never less than zero. The communica

Re: Missing requirement in draft-sparks-genarea-imaparch?

May I suggest that the specific details of this be left to the implementation effort. What is easy to implement in this area depends significantly on what platform (and here I mean more imap libraries and imap server technology than say python vs ruby vs .net vs C) A simple requirement like the im

Re: Missing requirement in draft-sparks-genarea-imaparch? (was Re: New Version Notification - draft-sparks-genarea-imaparch-05.txt)

On 3/28/13 1:17 PM, SM wrote: Hi Eric, At 05:13 28-03-2013, Burger Eric wrote: Rather than guessing all of the bad things that could happen, I would offer it would be better to say what we mean, like: The IMAP interface MUST NOT provide any IMAP facilities that modify the underlying mes

Re: Last Call: (Security Implications of IPv6 on IPv4 Networks) to Informational RFC

On 04/01/2013 06:14 PM, SM wrote: >> prevent them from attempting to connect to an IPv6 address and >> failing is not broken DNS. > > If there isn't any IPv6 connectivity it is useless to query for RRs > as the host is not going to establish an IPv6 connection. Instead of > looking at the p

RE: Last Call: (Security Implications of IPv6 on IPv4 Networks) to Informational RFC

At 10:59 01-04-2013, George, Wes wrote: Since I was the one that provided some of this text and raised the issues it's addressing, I'll take a crack at responding at a couple of your concerns below. Ok. [WEG] It doesn't. This is a second-order effect, but IMO an important one. If one is att

Re: Last Call: (Security Implications of IPv6 on IPv4 Networks) to Informational RFC

Hi Fernando, At 05:49 01-04-2013, Fernando Gont wrote: Please re-read the above paragraph -- you missed the part that says "...the same security policies". I saw that. :-) I commented on Section 6 first as it's only when I reached that part of the document that I saw the trade-off between bl

Gen-art review: draft-ietf-6renum-gap-analysis-05.txt

I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at . Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-6renum-gap-analysis-05.txt R

RE: Last Call: (Security Implications of IPv6 on IPv4 Networks) to Informational RFC

Since I was the one that provided some of this text and raised the issues it's addressing, I'll take a crack at responding at a couple of your concerns below. > -Original Message- > From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of > SM > >'Upstream filtering of

Re: [OPSEC] Last Call: (Security Implications of IPv6 on IPv4 Networks) to Informational RFC

Brian, On 03/29/2013 10:38 AM, Brian E Carpenter wrote: > > My minimal request for this draft is for my name to be removed from > the Acknowledgements, as I do not think that my comments have been > acted on. That has been my intent, and I sent a note before publishing one of the latest revs to

Re: Last Call: (Security Implications of IPv6 on IPv4 Networks) to Informational RFC

SM, On 03/31/2013 06:29 AM, SM wrote: >> The IESG plans to make a decision in the next few weeks, and solicits >> final comments on this action. Please send substantive comments to the >> ietf@ietf.org mailing lists by 2013-04-12. Exceptionally, comments may be > > From Section 6: > > "In gene

Re: STEAM: BOF proposal for Berlin

Dear Daniel, IETFers: With regard to security, I'm afraid the proposed scope of work is covered to a large extent by a breakthrough patent application titled "Defending the namespace" for which the abstract reads: "This invention is about an global entity oriented declarative authentication

Re: STEAM: BOF proposal for Berlin

PORT 9 FROM OUTER SPACE

Re: STEAM: BOF proposal for Berlin

I thought the DRAFT proposal was very interesting, but it includes RFC2119 for a single throw-away bit of normative language. Port 9? Please! You already excluded port 9 with the language in the later paragraph on port allocation. So it's blatantly obvious that you are referencing RFC211

Re: STEAM: BOF proposal for Berlin

> STEAM: BOF proposal for Berlin > > You may have noticed a recent trend in the IETF towards very > lightweight protocols for the Internet of Everything. > > http://tools.ietf.org/html/draft-draft-draft is the most fully > developed proposal on the table today.  It is extremely lightweight by > si

Re: STEAM: BOF proposal for Berlin

Tony Hansen writes: > I'm thinking the enhanced RFC format proposed below should be dubbed > STEAM/PUNC. And anyone that participates in said work would be "STEAMed". -- Wes Hardaker SPARTA, Inc.

RE: [savi] Gen-ART review of draft-ietf-savi-threat-scope-06

Joel, Yes, I think you do have the right end of the question, and that new text looks ok, as the previous sentence introduces the gratuitous ARP. To summarize, we've decided to address two of the three concerns from the review of -06. The third concern that will not be addressed is: > a) the a

Re: [pkix] Gen-ART review of draft-ietf-pkix-rfc2560bis-15

On 3/29/13 5:17 PM, "Piyush Jain" wrote: >' "revoked" status is still optional in this context in order to maintain >backwards compatibility with deployments of RFC 2560.' > >I fail to understand this statement about backward compatibility. >How does "revoked" being "optional/required breaks back

RE: [pkix] Gen-ART review of draft-ietf-pkix-rfc2560bis-15

' "revoked" status is still optional in this context in order to maintain backwards compatibility with deployments of RFC 2560.' I fail to understand this statement about backward compatibility. How does "revoked" being "optional/required breaks backward compatibility? The only reason cited in th

Re:The Interconnection and Interoperability of Different Cloud-office Applications (IDCOA) with the HTML File Format draft-guo-idoca-with-the-html-file-format-00

Zhun : What are your I-D about? As I know , native office applications based on XML. Then you draft are about some product ,such as Google Docs, Microsoft Office 365, IBM Docs ,Zoho,ThinkFree,Cisco WebEx,Evernote...? Susie

Re: STEAM: BOF proposal for Berlin

I'm thinking the enhanced RFC format proposed below should be dubbed STEAM/PUNC. Tony Hansen On 4/1/2013 6:52 AM, Daniel Raft wrote: > STEAM: BOF proposal for Berlin > ... > 2) Finally, preparing for the global deployment of the > Internet-Enabled Smart Grid (IESG), and to further increase di

STEAM: BOF proposal for Berlin

STEAM: BOF proposal for Berlin You may have noticed a recent trend in the IETF towards very lightweight protocols for the Internet of Everything. http://tools.ietf.org/html/draft-draft-draft is the most fully developed proposal on the table today.  It is extremely lightweight by simply using UDP a