Re: last call comments for draft-ietf-6man-stable-privacy-addresses-06

- Original Message - From: "Christian Huitema" To: "Fernando Gont" ; "SM" Cc: "RJ Atkinson" ; Sent: Tuesday, April 23, 2013 6:02 PM Instead, the draft goes into great details on how to actually implement the random number generator. Apart from not being necessary, some of these detail

W3C standards and the Hollyweb

The Encrypted Media Extensions (EME, a.k.a. DRM in HTML5) specification is not a real DRM itself. It provides for add-on parts described as Content Decryption Modules that provide DRM functionality for one or more Key Systems. DRMs are obviously designed to be non-interoperable, and EME is a stan

Re: Gen-ART review of draft-ietf-karp-crypto-key-table-07

> "Black," == Black, David writes: I've been there too. I've had a number of recent discussinos with Pete about what the IESG is and is not happy with . I'll write something up and I'm sure he and the rest of the IESG will let us know if we got it wrong:-)

Gen-ART LC Review of draft-ietf-6man-stable-privacy-addresses-06

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-6man-stable-privacy-addresse

Re: Last Call: (A method for Generating Stable Privacy-Enhanced Addresses with IPv6 Stateless Address Autoconfiguration (SLAAC)) to Proposed Standard

One comment and one nit below. Comment: There are two places where it is implied that the algorithm in this spec mitigates most of the privacy issues associated with embedding IEEE identifiers in addresses. The first is in section 1: For nodes that currently disable "Privacy extensions" [RFC49

Re: Last Call: (Improving Awareness of Running Code: the Implementation Status Section) to Experimental RFC

On Apr 12, 2013, at 2:57 PM, The IESG wrote: > Abstract > > > This document describes a simple process that allows authors of > Internet-Drafts to record the status of known implementations by > including an Implementation Status section. This will allow > reviewers and working groups

Re: Last Call: (Improving Awareness of Running Code: the Implementation Status Section) to Experimental RFC

At 14:57 12-04-2013, The IESG wrote: The IESG has received a request from an individual submitter to consider the following document: - 'Improving Awareness of Running Code: the Implementation Status Section' as Experimental RFC The IESG plans to make a decision in the next few weeks, and sol

Re: Gen-ART LC Review of draft-ietf-6man-stable-privacy-addresses-06

Hi, Ben, Thanks so much for your feedback! Please find my comments in-line... On 04/25/2013 03:39 PM, Ben Campbell wrote: > Minor issues: > > -- section 3, third paragraph from end: > > The paragraph suggests that changing the number of network interfaces > should be rare. I think it's quite co

Last Call:

Greetings, all, The idea put forth in this document seems quite useful, and the scope is appropriate for a process experiment, so I support its publication. I have only one comment on the content. In applying this to my own documents and WGs, I'd tend to prefer the "alternate" mechanism describ

Re: [Tools-discuss] Last Call: (Improving Awareness of Running Code: the Implementation Status Section) to Experimental RFC

On 4/26/13, Fred Baker wrote: > In 2013, I personally would accomplish this a little differently, however. A > section in an internet draft, which gets frozen when the draft is published, > is perhaps useful for the working group and IESG review processes. On the > other hand, it requires implemen

Re: Gen-ART LC Review of draft-ietf-6man-stable-privacy-addresses-06

On Apr 25, 2013, at 5:32 PM, Fernando Gont wrote: > Hi, Ben, > > Thanks so much for your feedback! Please find my comments in-line... > > On 04/25/2013 03:39 PM, Ben Campbell wrote: >> Minor issues: >> >> -- section 3, third paragraph from end: >> >> The paragraph suggests that changing the

Re: [Gen-art] Gen-ART LC Review of draft-ietf-6man-stable-privacy-addresses-06

On Apr 25, 2013, at 7:44 PM, Ben Campbell wrote: > So 6528 equally illustrates Steve Bellovin's work, and is also more current, > right? If someone decided to follow up to better understand your inspiration, > which draft would you prefer them to read? oops, s/draft/version.

Re: W3C standards and the Hollyweb

Personally, I don't have a firm position on these issues, but I couldn't let this pass by. On 25/04/2013, at 7:38 PM, Alessandro Vesely wrote: > The Encrypted Media Extensions (EME, a.k.a. DRM in HTML5) > specification is not a real DRM itself. It provides for add-on parts > described as Conte

Re: Gen-ART LC Review of draft-ietf-6man-stable-privacy-addresses-06

Hi, Ben, On 04/25/2013 09:44 PM, Ben Campbell wrote: >>> -- section 3, 2nd paragraph from end: >>> >>> You describe the affects of including Network_ID in some detail. >>> It would be helpful to note the consequences of _not_ including >>> it. >> >> Well, should we really do it? -- after all,

Re: Gen-ART LC Review of draft-ietf-6man-stable-privacy-addresses-06

Hi, deleting sections that seem resolved: On Apr 25, 2013, at 8:12 PM, Fernando Gont wrote: [...] > > -- 1, paragraph 11: "This document does not update..." How is adding an alternative algorithm _not_ an update? >>> >>> Well, you still send an RS, receive an RA, and generate

Re: last call comments for draft-ietf-6man-stable-privacy-addresses-06

Further to that, ifindexes of tunnels and PPP sessions can change dynamically as the bearer connection goes up and down, even if the interface has the same name and authenticated identity. That raises the interesting question of whether even the interface name is stable, as on many systems it is p

Weekly posting summary for ietf@ietf.org

Total of 96 messages in the last 7 days. script run at: Fri Apr 26 00:53:03 EDT 2013 Messages | Bytes| Who +--++--+ 9.38% |9 | 8.36% |68598 | fg...@si6networks.com 4.17% |4 | 7.84% |64307 | ted.i...@gma

Re: Last Call: (Improving Awareness of Running Code: the Implementation Status Section) to Experimental RFC

Reply to your request 12.04.2013 Reviewer: Abdussalam Baryun (AB), Date: 26.04.2013 Sub: comments for I-D: draft-sheffer-running-code-04 ++ The participant reviewer supports the document, very interesting and helpful, my recommendations and comments below, Ove

RE: Last Call: (Improving Awareness of Running Code: the Implementation Status Section) to Experimental RFC

Hi SM, > I have read every word in this document multiple times mainly in the > order they were written. :-) Hmmm, you can't be sure what order we wrote them. You can only know what order they are presented in :-) > In Section 1: > >"The scope of the intended experiment is all Internet-Draf