[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: terminolgy was Re: NETCONF Notifications: Consensus Points

Tom Petch wrote:


Notification as a term I queried for two reasons, one being that I was unclear
whether or not you were using it in the SNMPv3 sense, and I still don't know the
answer.  I see it used in security (PKI, EAP), CCAMP (probably borrowing from
ITU-T), congestion (FECN) etc but only defined in SNMPv3.


I'm using the term as it was defined first in the English dictionary:

http://www.m-w.com/dictionary/notification

   Function: noun
   1 : the act or an instance of notifying
   2 : a written or printed matter that gives notice



So I would like some clarification as to what you mean by it, as opposed to
event message.  You prefer the former but why, what distinction are you drawing?

(My second reason is editorial, that event it used in so many places in the
draft that I anticipate a lot of editing if notification is preferred to event)




This is not a WG draft.
There will be many edits made if this becomes a WG draft.


Tom Petch




Andy


----- Original Message -----
From: "Andy Bierman" <ietf@andybierman.com>
To: <netconf@ops.ietf.org>
Sent: Friday, November 25, 2005 7:32 PM
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.

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).

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.

Transport-Level ACKs

 There is WG consensus that this feature is required.

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.

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.

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.



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



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





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