OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

kmip message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [kmip] Groups - kmip-https-profile-v1.0-wd04.pdf uploaded


Port 5696 is registered with IANA for kmip and that means registered for what is in the official specification and hence the TTLV encoding.

Although IANA assigns port numbers, they are not binding. There is no IANA police force. No doubt, when offering an open, public, or cloud service, then it makes lots of sense to use the IANA assigned port for that service. However, there are many organisations – including those providing a service for third party access – that do not use IANA assigned ports. Many of those organisations (and I have spoken to plenty of them), have policies in place to ensure that (some) assigned ports are not used “for security reasons”, and/or “ease of administration”.

 

Suggesting using 5696 for something other than the encoding defined would be like running KMIP on port 25 instead of SMTP

No. It’s more like using port 25 for SMTP/HTTP. Not good for open, public interop, but works just fine for cooperating peers.

 

you can of course technically do that however that isn't what a client would expect.

Using this reasoning, KMIP/TTLV/HTTP/TLS should not use port 5696 either – whether or not KMIP/TTLV/TLS uses 5696. I don’t understand why the proposal allows KMIP/TTLV/HTTP/TLS on port 5696 as long as KMIP/TTLV/TLS also uses 5696, but disallows it otherwise. If 5696 is not the “right” port for KMIP/TTLV/HTTP/TLS, then why allow it all? If it is okay, then why require KMIP/TTLV/TLS to also use the exact same port at the same time on the same server?

 

From a pragmatic point of view, if you offer services on port 5696 you really need to ensure that the server on that port will respond in a manner that a client using the officially registered port would expect.

Not necessarily. For public access to the service it makes sense. But as I said above, there are many organisations that purposely do not allow this. And for some services in fact, they put policies in place to specifically disallow use of the assigned port. (Isn’t this also the main reason for this profile – organisations not providing access to port 5696?)

 

If you elect to not support TTLV then you will impact interoperability

No. If you elect not to use port 5696 then you will impact interoperability. So let’s carry KMIP through a port that’s usually open, say port 443, and lets ensure that we wrap KMIP in a protocol that can get through proxies, and firewalls, say HTTPS. This makes sense. Why complicate it with rules on combinations of protocols and port number usage?

 

If you elect to not support TTLV then you will impact interoperability

At no time have I said that TTLV should not, or would not be supported. I am trying to understand what the compelling reason is for forcing all implementations of this profile that want to use port 5696 (for whatever reason – it’s not my business to direct customers’ policies), to also concurrently support KMIP/TTLV on the same port. (For the record, I have no problem with allowing this. The QLab’s server will do this when we get around to coding it. My concern is forcing this behaviour on all implementations and all end users by making it a requirement.)

 

Naturally enough you can elect to ignore the conformance statements in the specification, the profile, and this document

It is only this proposal that forces the issue of having to support KMIP/TTLV/TLS on port 5696 if 5696 is also used for KMIP/TTLV/HTTP/TLS. There is no other KMIP document that would deem an implementation non-compliant if KMIP/TTLV/TLS uses a port other than 5696. If the aim is to force KMIP implementations to use port 5696, then that should be made a requirement in the KMIP specification, not as a side effect of configuring the port for the HTTPS profile.

 

John



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]