>
>>
>> However, if people are irreconcilably opposed to the scope of the
>
> "irreconcilably" is just rhetoric - I am opposed based on the
> arguments given, there's no need to try make that sound like
> it's unreasonable.
>
Point taken. I’ll clarify my original email by asking that you please
substitute "if people are irreconcilably opposed to the scope of the current
document ..” with "if the outcome of the call to adopt the document is rejected
for reasons that the scope is not acceptable…”
>> current document, then I propose as follows:
>>
>> a. Reject the call for adoption by the working group and move the
>> document back to the independent submission stream. I believe the
>> conflict review comments have already been adequately addressed in
>> draft -04 and publication will hopefully be possible there. b. Begin
>> a discussion here (or in whatever forum might be more appropriate) on
>> what would be an appropriate scope for a separate document to
>> consider the broader issues that are being raised by the various
>> commenters and see what sort of consensus can be reached. I offer to
>> contribute my opinion to that discussion.
>
> That's up to you, the ISE and the IESG and doesn't need any WG
> action.
>
> But I'm not clear - are you saying you no longer want the draft
> to be adopted? If that's the case, we're done with this thread.
>
What I’m saying is that I judge that the sentiment in the group may be more
amenable to development of a new scope and beginning work from there, rather
than adopting the current document.
I don’t see that the rejection of the document needs to bring an end to the
discussion of scope. However, how might such a discussion meaningfully proceed?
>> I do
>> address in section 9 the privacy implications of the specific
>> proposal
>
> I disagree with the above assertion. "mention" != “address"
Well, I’m not sure exactly what else needs to be said on the topic addressed by
the document. Can you indicate to me how you think the treatment of the privacy
implications is insufficient?
Briefly, I summarise the position laid out in the document as follows:
Problem: there is an information gap between records maintained by CGNAT
operators and internet-facing server operators. How to close that gap?
Options: (a) CGNAT operators keep connection logs, (b) internet-facing server
operators keep source port records.
Privacy considerations:
connection logs are bad (greater impact of data breach, significant
implications for ISPs, etc. etc.)
source port logging has minimal additional privacy impact over and
above recording of IP address in logs, which is already routine
Conclusion: of the available options to close the information gap, source port
logging is the most privacy sensitive way to achieve this
I’d be interested in hearing why you think this argument is not adequate?
>
>>
>> I think a discussion of the broader issue requires robust and vocal
>> representation of both sides and I am willing to adopt for the
>
> We don't do "representation" here - which I agree makes it hard
> for some people who support the traditional LEA position to take
> part in discussion.
>
I’m not adopting a “traditional LEA position” - all I’m saying is that more
consideration needs to be given to the counterbalancing arguments against total
privacy.
>> purposes of such a discussion the, apparently unpopular, position
>> that while the right to privacy is very important it is not the only
>> right and a more nuanced consideration of the situation might be
>> worthwhile.
>
> I'd love to see a discussion of requirements (not mechanisms) in
> this space. IMO the "record it all just in case" type of requirement
> is no longer appropriate when logging related to Internet protocols,
> given current and likely future uses for Internet protocols.
>
I completely agree that “record it all just in case” is not a priori the best
solution but there is certainly an under-represented need. I also agree that
it’s better to start with the actual requirements and work forward to
considering how those requirements can be achieved in a privacy sensitive way.
daveor
_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area
