Re: Proposed Update to Netconf Charter

[Andy Bierman <ietf@andybierman.com>]

Sharon Chisholm wrote:

<chair-hat-on>
I have some real concerns with the wording of this charter text,
but rather than focus on that, let's just try to agree on a bullet list
form of the charter.

I would much rather see agreement on specific features first,
(and then let people propose solutions, from which the WG
may select starting points for 1 or more standard documents),
rather than have the WG deal with an ad-hoc array of individual
submissions, as they come in.
</chair-hat-on>

[In the interest of transparency,  I am posting my
personal preferences for charter extensions]

<chair-hat-off>
Clearly, the addition of notifications is important to many people,
and its already in the charter, so that seems like a no-brainer.
However, a clean solution across all application mappings was
not achieved in the first attempt, so let's see what new ideas
come in this time around..

I also think that core data types are critical.
There is actually no reason whatsoever this document couldn't have been
published years ago -- it has no coupling to NETCONF at all -- it is just
more XSD types to NETCONF.

Access control is also critical to get in place early on.
I prefer to start simple and evolve the complexity over time.
IMO, a mapping to ISMS should be a separate work effort,
and probably in that WG.

NETCONF AC is unique because it is both "RPC method" and document oriented.
IMO, old approaches like VACM will be clumsy and/or bloated if applied
to NETCONF.  Some new innovation is required  here.

I am also interested in the "SW image load" channel that has been
discussed in the past.  Often config reloads are coupled with image
reloads, and it would be nice if NETCONF could integrate some
SW image management features to support this requirement.
</chair-hat-off>

Andy


> hi
>
> As promised, here are the proposed updates to the  Netconf charter to cover
> the work coming down the pipe:
>
> "Additional phase 2 work including:
>
> - Requirements and Guidelines for defining Netconf content to enable
> interoperable, high-quality and usable netconf implementations. Requirements
> will be defined around specification language,  access control, compliance,
> backwards compatibility, depicting relationships, event specification, and
> application error message specification.
>
> - An initial set of application-level re-usable data types such as IP
> Addresses, MAC addresses, etc. This definition would be compliant to the
> above defined requirements and guidelines for Netconf content.
>
> - An XML Schema for reporting information about the Netconf system. This
> definition would be compliant to the above defined requirements and
> guidelines for Netconf content.
>
> - A netconf protocol specification for asynchronous messaging to enable the
> sending of events. This must preserve the netconf layers."
>
>
> Sharon Chisholm
> Nortel 
> Ottawa, Ontario
> Canada
>
> --
> 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/>