Noreply (was: Last Call: (A YANG Data Model for IP Management) to Proposed Standard)

Hi Clint, At 13:39 22-04-2013, Clint Chaplin wrote: Why did this (and the other most recent) last call also not go to IETF-Announce? Here are some partial headers: From: The IESG To: IETF-Announce:; Subject: Last Call: (A YANG Data Model for Interface Management) to Proposed St

Re: Last Call: (A YANG Data Modelfor IP Management) to Proposed Standard

Original Message - From: "Clint Chaplin" To: "IETF Discussion List" Cc: Sent: Monday, April 22, 2013 9:39 PM > Why did this (and the other most recent) last call also not go to > IETF-Announce? And I was wondering why I got four copies of it, three on April 20th, one on April 22nd. Pa

Re: Last Call: (A YANG DataModel for Interface Management) to Proposed Standard

David A thoughtful assessment, and what it brings out for me is that we do not have an Information Model:-( That is, we could have reverse engineered an Information Model from the IF-MIB and then produced a data model in YANG, but that did not happen. Rather, there is a new and different (implic

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

Hi, > >> I'm not thinking of today but the future.  And yes, another >> argument would be that there isn't enough address space for this to be >> effectively private.  Those are two different issues, but fixing the >> boundary here reminds me of mistakes we made with IPv4 way back when.

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

On 04/22/2013 03:39 PM, SM wrote: > 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. There's some discussion

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

>> Sorry I wasn't clear: what is the benefit of specifying the algorithm, >> when simply popping out another PRF will in just about any instance do >> the job (unless you are reinitializing the PRF with the same seed)? > > There seems to be a disconnect here: > > We want an algorithm that, roughl

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

After reading the document again, the main issue is that the document specifies a solution to a problem by detailing a specific implementation, but does not explain the design choices behind that solution. As such, we end up with an over constrained specification, which at the same time fails to

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

Hi, Christian, On 04/23/2013 12:02 PM, Christian Huitema wrote: > After reading the document again, the main issue is that the document > specifies a solution to a problem by detailing a specific > implementation, I personally disagree (see below). > but does not explain the design choices behi

"emerging regions" IETF/IRTF discussion list

Hi, On Apr 17, 2013, at 14:50, "Eggert, Lars" wrote: > I've been talking to a few folks about whether there would be interest and > energy for a new IRTF RG focusing on - for the lack of a better term - > "Internet challenges and solutions for emerging regions." Basically, a forum > where we c

Re: "emerging regions" IETF/IRTF discussion list

CORRECTION: The list got created under irtf.org, i.e.: Subscribe at https://www.irtf.org/mailman/listinfo/ericas and email the list at eri...@irtf.org. Lars (The list creation message I got from the system said it was created under both the IETF and IRTF domains, but apparently not.) On Apr 2

Re: "emerging regions" IETF/IRTF discussion list

On 04/23/13 13:44, Eggert, Lars allegedly wrote: > CORRECTION: The list got created under irtf.org, i.e.: > > Subscribe at https://www.irtf.org/mailman/listinfo/ericas and email the list > at eri...@irtf.org. If you subscribe at ietf, you get a confirmation request from irtf. :-)

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

On 04/23/2013 11:41 AM, Christian Huitema wrote: >> You might argue that, clearly, the autoconf prefix needs to be part >> of the seed (I'd personally not expect developers to figure this >> one out). > > This is the kind of attitude that really does not go well with actual > developers. You are b

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

> If I'm the guy producing a spec, my goal is to produce a spec that is clear > as possible, and only leave open those bits that are necessary to leave open. Well, that might work for internal specs when you are managing a project, but that's probably not the right way to approach standards. A s

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

On 04/23/2013 07:45 PM, Christian Huitema wrote: >> If I'm the guy producing a spec, my goal is to produce a spec that >> is clear as possible, and only leave open those bits that are >> necessary to leave open. > > Well, that might work for internal specs when you are managing a > project, but th

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

Hi Fernando, At 09:36 23-04-2013, Fernando Gont wrote: What (specifically) do you have in mind? Both RFC4941 and this document note that if you use the underlying IEEE identifier for the IID, that becoames a "super cookie" that allows correlations. Is the much more to say on the subject than that

Gen-ART review of draft-ietf-pcp-upnp-igd-interworking-07

I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-pcp-upnp-igd-in

RE: [Gen-art] Gen-ART review of draft-ietf-pcp-upnp-igd-interworking-07

Grrr, typo in the subject line. That should be draft version -08, as correctly referenced below. Sigh. -Peter -Original Message- From: gen-art-boun...@ietf.org [mailto:gen-art-boun...@ietf.org] On Behalf Of Peter Yee Sent: Tuesday, April 23, 2013 10:57 PM To: draft-ietf-