Subject: RE: NETCONF Notifications: Consensus Points

From: "Glenn Waters" <[email-masked]>
Date: Fri, 25 Nov 2005 15:46:53 -0500

Inline.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
On
> Behalf Of Andy Bierman
> Sent: Friday, November 25, 2005 13:32
> To: [email-masked]
> Subject: NETCONF Notifications: Consensus Points
> 
> Hi,
> 
> I'd like to try to gauge WG consensus on some recent
> mailing list issues.  Please object if you think I've
> totally got it wrong:
> 
> Terminology:
> 
>   The term Notification is preferred over Event Message.

I'm OK with this.

> Max Message Size:
> 
>   A NETCONF peer should advertise its max message.
>   The standard should not set a max-size although it is
>   understood that implementations can use a max message size.
>   There seems to be some consensus for mandating a minimum
>   value for this parameter, although it's not clear what the exact
>   should be (something between 1500 and 65535 bytes).

This sounds like something that should be in the Netconf base protocol.
Notifications are not special. I propose that we do nothing here.

> Application-Level ACKs
> 
>   It is not clear what a sender would do differently even
>   if it knew the receiver did not understand the message.
>   Without specific features in the protocol which would
>   need app-level ACKs (such as data model version negotiation),
>   the cost and complexity of this feature cannot be justified.

I think that we require Netconf Notification ACKs, and they can be
optional as was done in SNMPv3 (i.e.: unACKed traps, ACKed informs).
They are required for cases where the sender needs to know if the
information was successful transmitted and may decide to retransmit at a
later time.
 
> Transport-Level ACKs
> 
>   There is WG consensus that this feature is required.

Is there such a thing as a transport level ACK for SSH? Elliot has made
it clear that there is a transport level ACK for BEEP.
 
> Feature Consistency at the Protocol Layer
> 
>   There is WG consensus that the protocol-level notification
>   features must be consistent across the supported transports.
>   However, there is not yet WG consensus that NETCONF over SOAP
>   must be supported.  The discussions have focused on SSH and BEEP.
>   Each time it is mentioned that SOAP/HTTP cannot support this
>   feature, the issue is ignored.

I agree that notification features are must be consistent regardless of
transport.

I'm not sure what you are proposing for SOAP. Sounds like you are
proposing that we kill that transport. Please clarify.

> Notification Info Model/Payload
> 
>   There is WG consensus to reuse syslog classification, although
>   the ability to transfer additional user data (similar to the OBJECTS
>   clause in an SNMP notification) is also required.  The option
>   of asking the SYSLOG WG for enhancements to RFC 3195 is also
>   possible, and some WG members prefer this approach if syslog
>   is going to be enhanced in any meaningful way.

I don't have an opinion on this yet, however, this does feel like we
will constrain ourselves too much.
 
> Events Draft as Starting Point
> 
>   There is WG consensus to use draft-chisholm-netconf-event-01.txt as
>   the starting point for this work, even though there are strong
>   objections to specific details in the draft.  It is understood
>   that the WG is addressing the feature list in the WG charter,
>   not in this draft, if the two are in conflict.

I agree.

Regards, /gww 

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>

---

From: Andy Bierman <[email-masked]>
Date: Fri, 25 Nov 2005 13:26:20 -0800

>Notifications are not special. I propose that we do nothing here.

I don't understand this logic.
How does doing nothing address the problem?
IMO, it should be addressed, regardless of the
document that contains the text.  I saw a lot of email
agreeing that advertising the max-message-size needs to be added.

>information was successful transmitted and may decide to retransmit at a

I'm not sure we are all clear on the semantics here.
What I think we mean by application-layer ACK
is the receiver understood the message.  TCP lets
us know the receiver got the message.

I don't see how retransmitting at a later time will
help the receiver understand the message (delivered as sent)
any better, unless the reason the message was garbled is
an intermittent bug in the sender.  I don't think we need to
worry about this case in the protocol.  Because if this isn't the case, then
the exact same error condition will occur no matter how
many times the sender retries.

>it clear that there is a transport level ACK for BEEP.

I'm thinking of TCP here.
I understand this will not catch buggy implementations sending malformed 
XML.
I don't agree that the protocol should be designed to accommodate buggy 
implementations.

>proposing that we kill that transport. Please clarify.

If nobody is implementing it, then we can't let its limitations impact 
this work.
I've heard one vendor tell me they would probably implement it if some 
customer really
wanted it, but I haven't heard of any products using the SOAP/HTTP or 
SOAP/BEEP
transports.  If you are out there, please speak up!

>will constrain ourselves too much.

Well, I have a different take on constraints -- like "real-world proven 
operational requirement".
Experiments should be done in the IRTF. 
We should standardize stuff that has been shown to work.

>>  not in this draft, if the two are in conflict.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 28 Nov 2005 16:21:22 +0100

> many times the sender retries.

My understanding is that a netconf protocol does not exist in
isolation and that most events that trigger netconf notifications will
originate in other pieces of software. For some pieces of software,
"shout and forget" is all what is needed. Other applications may want
to know whether they were heard so they can for example flush entries
in notification logs (as Randy mentioned).

If we don't provide application layer acks for those apps who need it,
then these apps will end up using TCP acks as the only approximation
for the indication that everything went fine. Such a best guess may
work, but it surely is not what I would call a robust solution (but
who cares about this these days).

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

---

From: Eliot Lear <[email-masked]>
Date: Mon, 28 Nov 2005 16:42:28 +0100

To review, the times when one needs an "application level
acknolwedgment" (ALA) is when the data has received and acknowledged by
the sender, and further processing then fails.  The classic example is a
disk failure.

Well, what comes next?  If further processing fails does the receiver
remain up or can it tear down the connection if its configuration
dictates?  If not, then ALAs are needed.

If so, the other end has a signal that there is in fact a problem, and
that it should follow its policy (for instance, going to backup server,
re-establishing connection, what-have-you).  At that point, if
notifications are general in nature (e.g., not related to configuration,
then one could argue that unless alarms are part of the architecture,
ALAs will be needed because traipsing through device state searching for
faults is probably cost prohibitive.

If the notifications are related to configuration alone, will the new
notification recipient be able to retrieve sufficient state to determine
a configuration change in the device?  If the answer is yes, then no
ALAs are needed.

Right or wrong?

Eliot

---

From: Andy Bierman <[email-masked]>
Date: Mon, 28 Nov 2005 08:23:40 -0800

>who cares about this these days).

You are absolutely correct that this confirmation mechanism
is needed -- and we already have it -- RPC.

Define an rpc:  <notify-confirm> and have the manager call it
to ACK one or more notifications.  If the 'ack-required' flag
is set in the notification, then the agent will expect the manager
to call this RPC, and if it does not, the agent can assume the manager
didn't get it or understand it.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 28 Nov 2005 18:12:44 +0100

> didn't get it or understand it.

A poor soul asked for an ACK, you try to sell him an ACK which will
lead to another ACK. Why not give him what he asked for, an ACK?

    If NETCONF server wants to send an acknowleged notification, then
    the notification is sent via an <rpc/> element which will be
    acknowledged by an <rpc-reply> element. If a NETCONF server wants
    to send an unacknowledged notification, then it uses the yet to
    be defined and agreed one-way RPC mechanism.

What is wrong with that?

/js

---

From: Andy Bierman <[email-masked]>
Date: Mon, 28 Nov 2005 12:12:12 -0800

>    be defined and agreed one-way RPC mechanism.

Because I don't think it is good engineering to add a lot
of complexity for an optional-to-implement feature.
There is way too much of that "kitchen-sink" approach in the IETF.

Let's make it mandatory for everybody to implement if it's worth having.
How many people still want it then?

Andy

---

From: "David B Harrington" <[email-masked]>
Date: Tue, 29 Nov 2005 17:05:58 -0500

Hi,

I personally prefer "notification" to "event message" because I would
like to see consistency in the terminology used for IETF O&M
protocols. There seem to be three variations - notification, event
notification, and event message; everywhere event notification is
used, the same document also refers to it simply as a notification,
and no document seems to identify what other type of notification
besides event notification is possible. 

Here's my research on the use of "notification" vs. "event message" in
O&M documents:

"notification" - SNMP (rfc3413), IPFIX requirements (rfc3917),
Diameter (rfc3588), Syslog (rfc3164), Opsec Practices
(draft-ietf-opsec-current-practices-02)  

"event message" - Syslog (rfc3164), netconf
(draft-chisholm-netconf-event-01.txt) 

Widening this to a search of RFCs which use notification or event in
their title, and checking for "notification" or "event message" in the
text of the document:

"notification" - Simple New Mail Notification (rfc4146), Requirements
for IPP Notifications (rfc3997), Internet Printing Protocol (IPP):
Event Notifications and Subscriptions (rfc3995), The SPIRITS (Services
in PSTN requesting Internet Services) Protocol (rfc3910), A Presence
Event Package for the Session Initiation Protocol (SIP) (rfc3856),
Message Disposition Notification (MDN) profile for Internet Message
Access Protocol (IMAP) (rfc3503), An Extensible Message Format for
Delivery Status Notifications (rfc3464), Simple Mail Transfer Protocol
(SMTP) Service Extension for Delivery Status Notifications (DSNs)
(rfc3461), Session Initiation Protocol (SIP)-Specific Event
Notification (rfc3265), The Addition of Explicit Congestion
Notification (ECN) to IP (rfc3168), An INVITE-Initiated Dialog Event
Package for the Session Initiation Protocol (SIP) (rfc4235), Session
Initiation Protocol (SIP) Extension for Event State Publication
(rfc3903), etc.

"event message" - 

Nuff said?

David Harrington
[email-masked]