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

Re: xmlconf-spec-01 comments

Wes,

Great comments. In line.

Wes Hardaker wrote:

- Section 2.2 on Security and Privacy say that connections must
  provide "security" and privacy.  "security" is a very very vague
  term and is not suitable in this case to define anything concrete
  (for one thing, it means different things to different people).
  What is it that you're really trying to say here?  Authenticated
  connections?  Integrity protected connections?  You've already
  covered privacy, so...

Right. "security" and "privacy" are bad words. How about replacing them with confidentiality and integrity?


- Also note that it's still illegal (I believe) in some countries to
  use and/or export products that enable encryption.  You should be
  careful when using the word 'MUST' in the future (it currently
  doesn't use capitalized terms)

I think that's a vendor issue. What encryption occurs needs to be a deployment option, as always.


- last p of section 2.3: So authorization must happen in a
  vendor-specific manner, possibly in addition to a standards-based
  manner (to be defined later).  What if the xmlconf session over some
  protocol X doesn't map to an internal user as the vendor had them
  defined?  This seems to bring on the requirement that all
  authentication mechanisms must map a connection to a real internal
  (vendor-specific) user?

I think this boils down to certain limits on the size of strings that will represent users. The use of the phrase "internal user" is possibly a poor choice. The point is that they should be principles that can be authorized for specific forms of access to various objects and functions. How's that for a nice generalized statement?

Eliot



--
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/>