I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
Please resolve these comments along with any other Last Call comments
you may receive.
Document:
The wording on this topic in this section and in the security section
(9.1) are not really as consistent as it should be in terms of normative
language - the security section describes the capabilities in terms of
what MUST be provided/implemented by a LIS and client implementation,
but not
Hi Mary,
The part I was trying to highlight was the lack of client device
authentication, not LIS authentication. If I read 9.1 right, it only
covers authentication of the LIS. I assume there is no expectation
that client devices present TLS certs to the LIS, right?
Again, I'm not saying
Hi Ben,
Thanks for your third Gen-ART review of this document. My responses are
inline below, with the exception of the Minor issue you highlight to
which I responded in a separate email.
Mary.
-Original Message-
From: Ben Campbell [mailto:b...@estacado.net]
Sent: Thursday, June 04,
Hi Ben,
So, you are talking about section 9.3 which does state that the LIS
ensures that the client is authenticated, per the following:
The LIS MUST
verify that the client is the target of the returned location, i.e.,
the LIS MUST NOT provide location to other entities than the target.
Again, my point was not to say that this was necessarily a problem--I
highlighted it as something the IESG should think about, knowing that
they have a big reading load. I guess my question is, is the statement
that reverse routability provides sufficient assurance in many
cases, along
I guess I'm still missing your original concern. But, one problem with
that sentence is that it's really out of context and would make more
sense if it were the first sentence in the last paragraph in section 8,
as that then leads to the text on the recommended mechanism (i.e., TLS).
The sentence
