[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: charter proposal - rev C
I want to react to a few things (AD hat on)
Wes responded to Andy:
> >>>>> On Tue, 22 Apr 2003 07:55:03 -0700, Andy Bierman
> <abierman@cisco.com> said:
>
> Andy> There have been few objections to using the XMLCONF draft as
> Andy> a starting point, made on the mailing list or at the BOF.
> Andy> There has been significant support for this draft from both
> Andy> vendors and operators.
>
> Andy> Those who believe the XMLCONF draft is the wrong approach
> Andy> are encouraged to publish alternative proposals.
>
> Andy, I didn't say it was the wrong approach (and in fact I've said in
> the past, though not in that message, that I think it's the right
> approach). [You're getting more and more defensive these days]. The
> point is merely that if I were writing the charter, I'd define the
> problem not the solution. Even if the xmlconf draft is going to be
> the proper solution, I don't think that the charter should be "make
> the xmlconf draft work".
>
The xmlconf doc is a "starting point", not said to be the solution.
Pls note that the ADs have been asking for concrete proposals before
we wanted to entertain any NETCONF WG proposals.
If people find that there should be counter proposals, then they better
get their act together and try to get well thought-out and well documented
proposals on the table. I would hate to see the WG wander off in all
sort of theoretical discussions.
> 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.
>
> Wes> This is a good example of how the solution wasn't listed even though
> Wes> BEEP will likely be a starting candidate.
>
> Andy> I disagree. The charter text was changed to explicitly remove the
> Andy> assumption that BEEP will be transport chosen. The WG will decide
> Andy> this issue.
>
> Sorry, my point was that it was a *good* replacement [I'm running on
> little sleep this week, so excuse me if I fail to make my ideas and
> questions come across properly at times]. Making it generic means
> it'll be easier to take alternative routes in the future if need be.
> I actually think the other portions of the charter should specifically
> be written in a similar fashion.
Would it help if we make the <TBD> a <TBD by the WG> ??
>
> (and in fact, if someone wanted to propose an alternative to XML they
> couldn't do so because the charter says the work will be based on the
> current XML draft.)
>
Not true. But as stated above, they better get their act together RSN.
And put their efforts/time/pounding-on-keyboeards where their mouth is.
> 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.
>
> Wes> I'm strongly opposed to justing having just the "security
> Wes> requirements" specified in the initial specifications.
>
> Andy> You are misinterpreting the WG deliverables. The transport
> Andy> independent protocol contains the requirements, and the
> Andy> transport specific mapping document specifies the details
> Andy> for that transport, including how the requirements are met.
>
> Andy> The authorization details are coupled to the data model. I
> Andy> don't think the IETF security requirements include mandated
> Andy> command-level or instance-level authorization mechanisms. The
> Andy> protocol will specify session-level authorization mechanisms and
> Andy> describe data-model requirements for finer granularity
> Andy> authorization.
>
> So, if I can summarize (and you correct me if I'm wrong):
>
> 1) The protocol specification will not include any notion of
> authentication (other than the fact that it assumes that
> authentication will have been done in some manner). This will be
> documented in the transport mapping ("Netconf over <TBD>").
>
> 2) The protocol specification will not include any notion of
> authorization, though it'll assume that somewhere something has
> made it impossible for the protocol engine to access to elements
> illegally. This will be documented in the data model (currently
> not within charter)?
>
> What about authorization for protocol specific operations? Who is
> allowed to do a copy-config from NAMED to RUNNING? Is that data model
> dependent too?
>
> What about error responses (tags, error codes, severity levels, etc)?
> Shouldn't the protocol define what the authorization errors will look
> like?
>
> It's very hard, and frequently dangerous, to make a protocol
> completely independent of the security mechanisms that will be used.
>
> As an aside, And is the authorization of the vendor-specific data
> format going to be documented? I assume that <format>text</format>
> requests will potentially be able to access elements that
> <format>xml</format> may not be able to access? It'll up to the
> vendors or operators to ensure their policies across the different
> data types are appropriately configured? It'll be impossible to
> standardize a way to say "add this user/authorization in standard way
> but deny them access to the vendor specific elements."? If so, that's
> going to be a potentially nasty security hole. At a minimum, new
> user/authorization configurations created via the standardized XML
> interface should default to no access via the vendor specific text
> format extensions unless explicitly enabled.
>
> Wes> As a suggestion to the ADs: the security area has been more and more
> Wes> open to protocol presentations at their SAAG meetings at the
> Wes> IETF.
> ...
> Andy> I think the security ADs will examine the charter proposal
> Andy> before they approve it, so presentations are not likely to
> Andy> be needed.
>
> I meant of the solution, not of the charter.
>
The security ADs will indeed make sure that the WG WILL be instructed to
do a decent job on the security aspects.
Hopefully we get enough security geeks to participate in the effort.
In that case we may not have to go to the SAAG. If not enough security
geeks do participate, then going there to present what we have been
thinking and where we may need help migth indeed be a good thing to do.
Bert
> --
> Wes Hardaker
> Network Associates Laboratories
>
--
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/>