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,
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-Drafts
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
Hi Fred,
Thanks for your review. Responding to you, and to other similar comments
on the list:
The draft refers to two styles of documenting implementation: in-line
in the Internet draft, and by a reference to (presumably) a database or
a wiki. The draft is also quite clear that the
On Fri 26/Apr/2013 02:53:58 +0200 Mark Nottingham wrote:
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 ves...@tana.it wrote:
DRMs are obviously designed to be non-interoperable, and EME is a
standard
Andrew == Andrew McGregor andrewm...@gmail.com writes:
Andrew Further to that, ifindexes of tunnels and PPP sessions can change
Andrew dynamically as the bearer connection goes up and down, even if the
Andrew interface has the same name and authenticated identity.
Andrew That
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq.
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-ietf-dhc-triggered-reconfigure-05
On Apr 26, 2013, at 2:12 AM, Yaron Sheffer yaronf.i...@gmail.com
wrote:
- There should be long-term commitment to maintain the data. I think we
simply don't have such processes in place, and personally I don't want to
even try to deal with this problem. I suspect that we'd have to
Given this thread on the ietf list, I guess I should forward the
following, which was done as a solicited Apps Area review for this draft:
Original Message
Subject: Review of: draft-sheffer-running-code
Date: Wed, 24 Apr 2013 06:38:24 -0700
From: Dave Crocker
On 4/26/13 10:58 AM, mohamed.boucad...@orange.com wrote:
Dear Robert,
Thank you for the review.
Please see inline.
Cheers,
Med
De : dhcwg-boun...@ietf.org [dhcwg-boun...@ietf.org] de la part de Robert
Sparks [rjspa...@nostrum.com]
Date d'envoi :
--On Friday, April 26, 2013 16:07 + Fred Baker (fred)
f...@cisco.com wrote:
On Apr 26, 2013, at 2:12 AM, Yaron Sheffer
yaronf.i...@gmail.com wrote:
- There should be long-term commitment to maintain the data.
I think we simply don't have such processes in place, and
personally I
Hi, Ole,
On 04/26/2013 06:11 AM, Ole Troan wrote:
If you want a stable address, you want to use something that
actually has the exact stability properties you require, and
interface indexes and names are seldom what you actually need.
could we simplify the hash to only include the prefix,
Hi, Alissa!
Thanks so much for your feedback! -- Please find my comments in-line...
On 04/25/2013 06:32 PM, Alissa Cooper wrote:
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
Hi, Andrew,
On 04/26/2013 12:43 AM, Andrew McGregor wrote:
Further to that, ifindexes of tunnels and PPP sessions can change
dynamically as the bearer connection goes up and down,
Would we be doing SLAAC for these?
even if the
interface has the same name and authenticated identity. That
Hi Adrian,
At 23:42 25-04-2013, Adrian Farrel wrote:
Hmmm, you can't be sure what order we wrote them. You can only know what order
they are presented in :-)
I like the finesse of the technical argument. :-)
I think you are right. Of course, individuals pushing drafts to the
ISE could do
On 26/04/2013 23:38, Alessandro Vesely wrote:
On Fri 26/Apr/2013 02:53:58 +0200 Mark Nottingham wrote:
Personally, I don't have a firm position on these issues, but I couldn't let
this pass by.
I've thought about this a bit and looked at some on-line discussions.
In as far as this might be
On Fri, Apr 26, 2013 at 12:59 PM, Brian E Carpenter
brian.e.carpen...@gmail.com wrote:
1. DRM is a fact of life, and it is therefore better that there should
be a well-formulated standard than a free-for-all. A free-for-all is a
guaranteed route to non-interoperability.
Crack cocaine,
OK, pardon the cheap shot, but I don¹t think SDOs that have some sort of
stewardship relationship to the Internet should ever play any part
whatsoever in the facilitation of DRM.
So it's ok to define protocols that manage access to services (e.g., TLS,
GSS, SASL, etc), but not to the content
On 04/26/2013 10:23 PM, Josh Howlett wrote:
OK, pardon the cheap shot, but I don¹t think SDOs that have some sort of
stewardship relationship to the Internet should ever play any part
whatsoever in the facilitation of DRM.
So it's ok to define protocols that manage access to services
Brian E Carpenter wrote:
3. EME should have a very low or zero cost of entry for a content provider.
DRM system are evil in any way you look at it.
Originally, copyright was a conceived as a temporary (50yrs) monopoly.
The protection period has in recent years been prolonged in many years
to
At 02:38 25-04-2013, 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 Content Decryption Modules that provide DRM functionality
for one or more Key Systems. DRMs are obviously
* Alessandro Vesely wrote:
If you haven't done so already, please sign the FSF petition:
http://www.defectivebydesign.org/no-drm-in-html5
The W3C is asking for comments on its Encrypted Media Extensions pro-
posal, including on whether W3C should continue work on the document, to
be sent to the
The Forwarding and Control Element Separation (forces) working group in
the Routing Area of the IETF is undergoing rechartering. The IESG has not
made any determination yet. The following draft charter was submitted,
and is provided for informational purposes only. Please send your
comments to the
23 matches
Mail list logo
