Re: [sip-clf] Problem Statement - Source/Dest Fields & Contact

[Saverio Niccolini <[e-mail]>]

2  IP address only

Cheers,
Saverio

> Can we get more opinions?
> 
> Should src/dst field in the mandatory logging be
> 1. DNS OR IP address (implementors choice)
> 2  IP address only
> 
> Thanks,
> 
> Peter Musgrave
> (as individual)
> 
> 
> On Thu, Oct 7, 2010 at 12:05 PM, Vijay K. Gurbani <[e-mail]>
> wrote:
> > On 10/07/2010 09:44 AM, Peter Musgrave wrote:
> >>
> >> I am very reluctant to leave this implementation defined.
> >> - if we can be specific in a draft, we should be
> >> - in some implementations (IPFIX) this could affect what kind of
> field
> >> is used for the mandatory entry
> >
> > Peter: If we make it an either-or decision, IPFIX can continue
> logging
> > raw IP addresses.
> >
> >> - I regard having the basic L3 "where the packet came from/went to"
> a
> >> basic and essential item of information when debugging using logs
> >
> > DNS names are just as useful in debugging, sometimes more than IP
> > addresses.  Again, I will concede that round-robin DNS makes a
> > stronger case for logging an IP address, but not all deployments use
> > round-robin DNS.
> >
> >> Is there a specific reason for wanting DNS if it available? (And
> would
> >> it be a unique DNS name not found in the reqUri, To or From)?
> >
> > The domain names in To, From are not of importance to SIPCLF.  It is
> > the resolution that results from rfc3263 lookup of the SIP AUS.
> >
> >> I continue to believe the IP should be mandatory - and if a DNS name
> >> is desired it can be in the extension info.
> >
> > I am afraid I'll have to respectfully disagree.  I think the
> > notion of only raw IP being mandatory is rather restrictive.
> > In the end it is a sequence of bytes of certain length.  The
> > semantic accorded to this sequence of bytes is that it can be an
> > IP address or a DNS name.
> >
> >> Also, the problem statement specifies "SIP CLF operates natively at
> >> the transaction layer ..." (5.1). I had taken this to mean it was
> >> logging at the level of the transaction state machines as per
> section
> >> 17 of RFC3261. Hence my view the logging is "close to the wire".
> >
> > I pointed out earlier that we should not make any assumptions about
> > how a particular piece of software is architected.  It may very well
> > be that the information on the target lookup is available at the
> > transaction layer.  If it is, why not log it?
> >
> > In the end, you as the chair have the unenviable task to determine
> > if rough consensus has been reached.
> >
> > I have made my case that we should allow for the logging of either
> > names or IP addresses.  Recorders that pull SIP packets off
> > the wire will most probably log raw IP addresses.  Others that log
> > in the application itself can have more flexibility, and we
> > should not inhibit this aspect.
> >
> > I will abide by any decision made through our consensus processes,
> > of course; although I will like to at least indicate my preference
> for
> > allowing both the formats to be logged.  The cost to doing so is low,
> > I believe.
> >
> > Thanks,
> >
> > - vijay
> > --
> > Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
> > 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
> > Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
> > Web:   http://ect.bell-labs.com/who/vkg/
> >
> _______________________________________________
> sip-clf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sip-clf



============================================================
Dr. Saverio Niccolini
Manager, Real-Time Communications Group
NEC Laboratories Europe, Network Research Division     
Kurfuerstenanlage 36, D-69115 Heidelberg
Tel.     [phone]
NEC*NET Phone: [phone]
Fax:     [phone]
e-mail:  [e-mail]
============================================================
NEC Europe Limited Registered Office: NEC House, 1 Victoria
Road, London W3 6BL Registered in England 2832014