RE: NETCONF Notifications: Consensus Points

["Glenn Waters" <gww@nortel.com>]

Inline.

> -----Original Message-----
> From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org]
On
> Behalf Of Andy Bierman
> Sent: Friday, November 25, 2005 13:32
> To: netconf@ops.ietf.org
> 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 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/>