> On May 9, 2018, at 4:29 PM, Brian E Carpenter <[email protected]>
> wrote:
>
>> IMO:
>>
>> - the IETF should speak to logging only when it relates to *protocol or
>> network diagnostics*
>
> That may be a bit narrow, which is why I prefer ...relates to *operational
> requirements*. And yes, that could include requirements over which the
> operator has no control, such as regulatory requirements. It's really not the
> IETF's business *why* an operator decides to log stuff. RFC 6302 is about
> *how* to log address information.
That’s disingenuous at best.
The RFC states:
...In the past, to support abuse mitigation or
public safety requests, the knowledge of the external global IP
address was enough to identify a subscriber of interest. With
address sharing technologies, only providing information about the
external public address associated with a session to a service
provider is no longer sufficient information to unambiguously
identify customers.
This isn’t about how to log. This is about why merely logging the old way
doesn’t suit a particular reason for logging.
>
>> - this means that the current document should not proceed
>
> A slightly different question from whether we should tackle the topic. I
> don't think the IETF would do itself any favours by tackling the topic. That
> doesn't mean the topic is unimportant, just that this is not the venue for it.
Granted - my reply could be suffixed with “here in the IETF”..
>
>> - this means that RFC6302 should be deprecated
>
> Why? It is about operational logging, and specifically says (end of section
> 2):
It’s not about logging at all; it’s about what needs to be logged to track
remote users behind NATs. There’s no justification given for needing to do this
for operational purposes. The only examples given are regulatory or commercial.
Joe
_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area