Hi Med, On 05/06/14 14:11, [email protected] wrote: > Hi Stephen, > > You referred in your message to an old version.
That was the one for which the adoption call was issued. I guess just a typo. I looked quickly at the diff between 04 and 05 and my conclusion remains the same and most of my comment I think still apply, despite the removal of the odd requirements section. S. > The latest version of > the document does not include any requirement, it is only an > inventory of use cases when problems are encountered. The latest > version is available at: > http://tools.ietf.org/html/draft-boucadair-intarea-host-identifier-scenarios-05. > > Some of these use cases are restricted to a single administrative > domain while others span multiple domain. Privacy concerns are really > important; these are discussed in RFC6967. > > The use cases are not theoretical ones, but are those where > complications arise. Explicitly calling out security risks (including > privacy ones) will benefit to this work. It is really helpful to > understand the use cases and call out any potential risks rather than > speculating without actual understanding of what the problem is. > > This document is the opportunity to record security and privacy > concerns that apply to these use cases. The content of the document > is not frozen. Adopting it as a WG document will undoubtedly enrich > it and benefit from other perspectives that those of the authors. > > Cheers, Med > >> -----Message d'origine----- De : ietf-privacy >> [mailto:[email protected]] De la part de Stephen >> Farrell Envoyé : jeudi 5 juin 2014 14:48 À : Hannes Tschofenig; >> [email protected] Cc : [email protected]; Zuniga, Juan Carlos >> Objet : Re: [ietf-privacy] NAT Reveal / Host Identifiers >> > > Hiya, > > On 05/06/14 08:05, Hannes Tschofenig wrote: >>>> If you want to review a document with privacy implications >>>> then have a look at the NAT reveal / host identifier work >>>> (with draft-boucadair-intarea-host-identifier-scenarios-04 >>>> currently in a call for adoption). >>>> >>>> I had raised my concerns several times now on the mailing list >>>> and during the meetings. > > I share those concerns. And adopting this without any consideration > of BCP188 would fly in the face of a very recent, very thoroughly > discussed, IETF consensus. For something like this, the onus ought > IMO be on the proposers to have done that work before asking for > adoption. Based on the draft, they clearly have not done that. > > We could also ask to add more use-cases: > > use-case#12: spy on everyone more easily, TEMPORA++ use-case#13: sell > data that's even more fine-grained than clickstreams use-case#14: > expose your n/w internals to help on path attackers use-case#15: > track hosts from which people emit "dangerous" utterances > use-case#16: block hosts from which people emit "dangerous" > utterances use-case#17: charge me more for using two of my computers > in my house > > The set of use-cases presented very much contradicts the explicit > claim in the draft that no position is being taken as to the merits > of this. IMO that argues strongly to not adopt this. > > One could also comment on the requirements that seem to require new > laws of physics or are otherwise pretty odd: > > REQ#1: seems to require knowing from packets passing by that a device > is a "trusted device" (and REQ#15 says that can be done with 16 > bits;-) Hmm... are those qubits maybe? > > REQ#5: *all* IP packets MUST have a HOST_ID... but presumably without > a flag day. Hmm... > > REQ#6: says this is a transport thing. Eh, why ask INT-AREA? > > REQ#10+REQ#11: MUST be intradomain only but MUST also be inter > domain. Hmm... > > REQ#18: receiver MUST "enforce policies like QoS." Huh? > > Such a frankly bogus list of "requirements" also means that this is > not something that ought be adopted in the IETF. > > I also think that this proposal has previously been proposed in other > ways and not adopted. Such forum-shopping is yet another reason to > not adopt it, and certainly not as an area wg thing without any > broader IETF-wide consideration. (As an aside: having to play > whack-a-mole with such repeat proposals is one of the downsides of > area wgs. Not sure if anything can be done about that though.) > > In summary: ignoring BCP188, the selection-bias in use cases, the > badly thought out "requirements" and forum shopping are all > independently sufficient reasons to not adopt this. And of course > that doesn't include all the other issues with potential solutions > listed in RFC6967 (the reference to which is oddly to the I-D and not > the RFC). > > My conclusion: this one ought go to /dev/null same as the previous > attempts to shop the same thing into other parts of the IETF. > > S > > >>>> >>>> Ciao Hannes >>>> >>>> >>>> -------- Original Message -------- Subject: [Int-area] Call >>>> for adoption of >>>> draft-boucadair-intarea-host-identifier-scenarios-04 Date: >>>> Thu, 5 Jun 2014 04:20:56 +0000 From: Suresh Krishnan >>>> <[email protected]> To: Internet Area >>>> <[email protected]> >>>> >>>> >>>> >>>> Hi all, >>>> >>>> This draft was originally intended to be published as an AD >>>> sponsored submission from the OPS area, but the authors have >>>> expressed their interest to continue this work in the intarea >>>> wg given that RFC6269 and RFC6967 originated here. The draft >>>> has been updated to address the issues brought up during >>>> earlier discussions on the wg mailing list and the latest >>>> version of the draft is available at >>>> >>>> >>>> >>>> http://tools.ietf.org/html/draft-boucadair-intarea-host-identifier- > >>>> scenarios-04 >>>> >>>> >>>> > This call is being initiated to determine whether there is WG >>>> consensus towards adoption of >>>> draft-boucadair-intarea-host-identifier-scenarios-04 as an >>>> intarea WG draft. Please state whether or not you're in favor >>>> of the adoption by replying to this email. If you are not in >>>> favor, please also state your objections in your response. This >>>> adoption call will complete on 2014-06-19. >>>> >>>> >>>> >>>> Regards >>>> >>>> Suresh & Juan Carlos >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ ietf-privacy >>>> mailing list [email protected] >>>> https://www.ietf.org/mailman/listinfo/ietf-privacy >>>> >> >> _______________________________________________ ietf-privacy >> mailing list [email protected] >> https://www.ietf.org/mailman/listinfo/ietf-privacy > > _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
