Re: [CDNi] I-D Action: draft-bertrand-cdni-logging-02.txt

["ietfdbh" <[e-mail]>]

Hi,

How long are CDNI log messages expected to be?
What are the requirements to be met in terms of confidentiality, integrity
checking, etc.?

RFC5424 syslog deliberately does not hard-code the length.
For interoperability, senders MUST support at least 2048, receivers SHOULD
support at least 8192 bytes.
For usages that need larger message sizes, such as HIPPA audit logs, you can
use larger message sizes.
However, each syslog sender/receiver/relay/application in the path to
deliver that data would need to support these larger sizes to avoid
truncation.

SNMP is designed to support traps as alerts, and to support trap-directed
polling.
Traps/Informs are typically small messages to alert the NMS on a timely
basis to some condition; small alerts typically better meet operational
alerting requirements.
You typically do not send lots of data in a trap/inform.
If there is a lot of information to be passed, a trap can be used to tell
the NMS something is available, and the NMS can then poll for the actual
data (or use a different protocol to get the data).
So, depending on what you plan to log, and the importance of timely
reporting, traps/informs may or may not meet operational requirements.

David Harrington
[e-mail]
[phone]
-----Original Message-----
From: Gene Golovinsky [mailto:[e-mail]] 
Sent: Monday, November 05, 2012 10:34 AM
To: [e-mail]; ietfdbh; [e-mail]
Subject: RE: [CDNi] I-D Action: draft-bertrand-cdni-logging-02.txt

Hi.

Some questions re usage of Syslog RFC 5424 were asked at the previous
meeting. Then, were also raised on the list. I did not see a technical
conversation about it. (May be I missed it). The same applies to SNMP
Informs.
I would too suggest that Syslog may be a better choice since it allows for
easier extension and longer massages.

The only argument I have heard against these two so far is that CDNi logs
may be too long.

Cheers.
--Gene


-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of
[e-mail]
Sent: Monday, November 05, 2012 07:22 AM
To: ietfdbh; [e-mail]
Subject: Re: [CDNi] I-D Action: draft-bertrand-cdni-logging-02.txt

David,

Thanks for your review of our draft.

1) We want the WG to discuss the choice of a Logging transport protocol for
non real-time information. Personally, I do not yet have a clear preference
for a given transport protocol. We definitely need to identify the pro /
cons of the candidate protocols and I would like to invite the WG
contributors to share their technical arguments on the mailing list.

2) Please see 1)   :-)

3) Thanks for sharing these arguments.

  To clarify the scope of the open technical questions:
        - I think there is consensus on the fact that the logging
information required by CDNs in the scope of CDNI in quite specific. So,
we need to define a   Logging format.
	  - There is no consensus for the moment on the choice of a Logging
transport protocol for non real-time information.
	    - The candidate protocols are: SNMPv3, Syslog, SSH File
Transport, HTTPS. Did I forget any relevant protocol?
          - Your point is that SNMPv3 and syslog (and any other candidate
protocol) must not be excluded without documenting technical reasons. I
definitely agree.

Note that we want to have a clear separation between the logging application
layer (the format of the information) and the logging transport layer. So,
the WG may decide to support more than on logging transport protocol.

Best regards,

Gilles


-----Message d'origine-----
De : [e-mail] [mailto:[e-mail]] De la part de
ietfdbh Envoyé : lundi 22 octobre 2012 23:17 À : [e-mail] Cc : David
Harrington Objet : Re: [CDNi] I-D Action:
draft-bertrand-cdni-logging-02.txt

Hi,

I took a quick look at this document.
I have a few comments.

1) While appendix C is yet to be written, the placeholders seem to already
poo-poo the candidates that are existing IETF standards, without documenting
why they are not viable choices.

2) Appendix C2 references RFC6707, which states some conclusions that have
no documentation as to how the conclusions were reached.
What are the scalability requirements for the CDNI logging interface?
RFC6707 states that there are "scalability concerns", but doesn't specify
the requirements or the specific concerns.
There may be valid scalability concerns, but this deserves better
documentation than mere handwaving.
Which scalability requirements are not possible to meet with SNMPv3?

3) RFC6707 states SNMP does not support guaranteed delivery of traps.
I am not sure how this conclusion was reached.
SNMPv3 has Informs (acknowledged traps), which support application-level
acknowledgement of receipt.
An SNMPv3 agent could continue to periodically send the Inform until it
receives acknowledgement of receipt.
This would seem to mitigate the concern that use of SNMP "could result in
log records being lost".
Note that SNMPv1 has been declared Historic, so shouldn't even be considered
a candidate protocol for new usage.
Only version 3 of SNMP is recommended.

That said, I would think that syslog [RFC5424] might be a better choice for
CDNI logging.
It uses secure, reliable transport over TLS (RFC5425).
Signed syslog messages [RFC5848] can be used by receivers to verify they
have received all the messages sent to them.
If messages are out-of-order or missing, the receiver can determine which
records are missing and request they be resent.
In addition, the signing can be applied to stored logs to verify they have
not been modified from the original message stream.

If you are considering the RECOMMENDED versions of these candidate
protocols, they might better meet the requirements.
But the main point is that the consideration process should be documented
more clearly than this document (or RFC6707) does.

David Harrington
[e-mail]
[phone]
-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of [e-mail]
Sent: Monday, October 22, 2012 2:59 PM
To: [e-mail]
Subject: I-D Action: draft-bertrand-cdni-logging-02.txt


A New Internet-Draft is available from the on-line Internet-Drafts
directories.


	Title           : CDNI Logging Interface
	Author(s)       : Gilles Bertrand
                          Stephan Emile
                          Roy Peterkofsky
                          Francois Le Faucheur
                          Pawel Grochocki
	Filename        : draft-bertrand-cdni-logging-02.txt
	Pages           : 43
	Date            : 2012-10-22

Abstract:
   This memo specifies the Logging interface between a downstream CDN
   (dCDN) and an upstream CDN (uCDN) that are interconnected as per the
   CDN Interconnection (CDNI) framework.  First, it describes a
   reference model for CDNI logging.  Then, it specifies the actual
   protocol for CDNI logging information exchange covering the
   information elements as well as the transport of those.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-bertrand-cdni-logging

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-bertrand-cdni-logging-02

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-bertrand-cdni-logging-02


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html or
ftp://ftp.ietf.org/ietf/1shadow-sites.txt

_______________________________________________
CDNi mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/cdni

__________________________________________________________________________
_______________________________________________

Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc pas etre diffuses,
exploites ou copies sans autorisation. Si vous avez recu ce message par
erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les
pieces jointes. Les messages electroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete
altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged
information that may be protected by law; they should not be distributed,
used or copied without authorisation.
If you have received this email in error, please notify the sender and
delete this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for messages
that have been modified, changed or falsified.
Thank you.

_______________________________________________
CDNi mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/cdni