Re: charter proposal - rev C

[Andy Bierman <abierman@cisco.com>]

At 07:40 AM 4/22/2003, Wes Hardaker wrote:
>>>>>> On Tue, 08 Apr 2003 16:22:31 -0800, Andy Bierman <abierman@cisco.com> said:
>
>I think the 3rd version of the charter looks much better than the
>previous two.  I've been away for a while and unable to respond to the
>previous ones but I was glad to see that many of the issues I had have
>already been taken care of.  A few remain though:
>
>Andy> The Netconf protocol will use XML for data encoding purposes,
>Andy> because XML is a widely deployed standard which is supported
>Andy> by a large number of applications. XML also supports
>Andy> hierarchical data structures and multiple character sets.
>...
>Andy> - XML namespace conventions
>Andy> - XML usage guidelines
>...
>Andy> The working group will base its work on the XMLCONF Configuration 
>Andy> Protocol <draft-enns-xmlconf-spec-00.txt>.
>
>In the past few years, the IETF went to a process of 'define the
>requirements within the WG first, then propose solutions'.  Now, much
>of the time a WG has followed right in line with what was originally
>being proposed, but not always.  The question is: is it wise to lock
>the solution into the charter at this point?  Is a requirement
>document going to be produced?  Or are we going to short-circuit the
>normal process in an effort to "speed things up"? (the last is
>probably a question for the ADs).  I'm all in favor of speeding things
>up, but the schedule and deliverables are deviating from what I
>thought the IETF was trying to do these days.

There have been few objections to using the XMLCONF draft as
a starting point, made on the mailing list or at the BOF.
There has been significant support for this draft from both
vendors and operators.

Those who believe the XMLCONF draft is the wrong approach
are encouraged to publish alternative proposals.


>Andy> - Netconf over <TBD> Specification, which defines how the
>Andy> Netconf protocol is used with the transport protocol
>Andy> selected by the group.  There will be a document of
>Andy> this type for each selected transport protocol.
>
>This is a good example of how the solution wasn't listed even though
>BEEP will likely be a starting candidate.

I disagree. The charter text was changed to explicitly remove the
assumption that BEEP will be transport chosen. The WG will decide
this issue.


>Andy> - Netconf Protocol Specification, which defines the
>Andy> operational model, protocol operations, transaction model, 
>Andy> data model requirements, security requirements, and transport 
>Andy> layer requirements.
>
>I'm strongly opposed to justing having just the "security
>requirements" specified in the initial specifications.  I thought the
>IETF was beyond the point where security was an add-on feature.  To
>get security right, it needs to be integrated from the beginning.
>Defining exactly how authorization and access control is done is a
>MUST, IMHO, from the beginning.  Retrofitting security later
>frequently can't be done properly in protocols, and major changes are
>needed to secure it later.  Note that I'm not saying that the goal of
>multiple integrated authorization mechanisms isn't achievable, I'm
>merely stating that the protocol itself needs to define how the
>negotiation is done up front.  When configuration of a network is on
>the line, it's unacceptable this day in age not to put security
>considerations at the fore-front of the requirements for new
>protocols.

You are misinterpreting the WG deliverables.  The transport
independent protocol contains the requirements, and the 
transport specific mapping document specifies the details
for that transport, including how the requirements are met.

The authorization details are coupled to the data model.
I don't think the IETF security requirements include
mandated command-level or instance-level authorization
mechanisms.  The protocol will specify session-level
authorization mechanisms and describe data-model
requirements for finer granularity authorization.

>As a suggestion to the ADs: the security area has been more and more
>open to protocol presentations at their SAAG meetings at the IETF.
>I'd strongly suggest that before a network configuration protocol gets
>to the standards track that it be reviewed by the security area
>experts, or that the security area ADs are at least tapped to get a
>few reviews from people under their area.  (maybe they'll be enough
>security folk interested in this group that shoulder tapping won't be
>needed, but it's probably too early to determine that).

I think the security ADs will examine the charter proposal 
before they approve it, so presentations are not likely to
be needed.


>To end on a positive note: overall, the charter looks well written.
>-- 
>"In the bathtub of history the truth is harder to hold than the soap,
> and much more difficult to find."  -- Terry Pratchett 

Andy




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