Re: none

[Phil Shafer <phil@juniper.net>]

Scott Lawrence writes:
>.... lots of great feedback ...

Thanks for this feedback. Lots of things we should fix in the
spec. I'll comment a bit on some issues, but I'm in agreement
with most of your points.

>  Personally, I think either should be allowed and that a requirement
>  that both MUST be supported by a receiver would be reasonable, but
>  one could also make the case that it's easier to just use 3076 to
>  the letter.

Yes, we tried to adhere to rfc3076, though we should add some
words about being flexible in receiving empty elements.

>  In the definition of the config element used in the get-config
>  operation (and perhaps elsewhere), the examples misuse the xmlns
>  attribute.

Not really misuse, but it makes that <get-config> element accept any
element, which isn't good. Given that the entire configuration should
appear as a single element, I'd like to see this as:

  <rpc id="101" xmlns="http://ietf.org/xmlconf/1.0/base";>
    <get-config>
      ...
        <config>
          <config-top foo:xmlns="http://example.com/schema/1.2/config";>
            <users></users>
          </config-top>
        </config>
      ...
    </get-config>
  </rpc>

This allows an application to take a full or partial configuration
document, wrap it in xmlconf and ship it to the router.

>  I would suggest adding an explicit indication by which an XMLCONF
>  implementation may indicate to a peer that the underlying transport
>  does not provide the level of protection which its own policy
>  requires (this might take the form of some indication in the
>  greeting message that additional profiles may be available using a
>  more secure transport).  

I'm not a security guy AID'tPOOTV, but the xmlconf library API should
give hooks for pulling out the trust information that should allow the
peer to decide that its security requirements are met. For example,
each side can pull out the peer's TLS certificate and decide if the
conversation is sufficiently secure to continue initialization.

Thanks,
 Phil

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