Hello Sean,
Thanks very much for your review, some proposals and answers from the
co-authors inline below to cover the points raised.
Best regards,
Peter
-----Original Message-----
From: insipid [mailto:insipid-bounces(_at_)ietf(_dot_)org] On Behalf Of Sean
Turner
Sent: 07 January 2017 02:57
To: secdir(_at_)ietf(_dot_)org
Cc: insipid(_at_)ietf(_dot_)org; ietf(_at_)ietf(_dot_)org;
draft-ietf-insipid-logme-reqs(_dot_)all(_at_)ietf(_dot_)org
Subject: [Insipid] Review of draft-ietf-insipid-logme-reqs-11
Reviewer: Sean Turner
Review result: Has Nits
After getting over my initial reaction that was something like "srsly!? we're
going to standardize the exact opposite of 'do not track'", I realized that
this
is a requirements draft for an IETF approved WG and a chartered work item
of that WG :)
0) s3.2: Is the intent to define a protocol mechanism to determine if the two
or domains are part of the same trust domain? This requirement could be
achieved by saying out-of-band bilateral agreements are the mechanism to
establish the domain.
There is no intent to define a protocol mechanism to determine if two or
more domains are part of the same trust domain. s3.2 explains the meaning
of the term "trust domain" as it is used in this draft because the term "trust
domain" does not have a fixed meaning throughout its use in RFCs. RFC 3324
section 2.3 defines "trust domain" for network asserted identity and this
definition is re-used by RFC 7316 for a private network indicator. "Trust
domain" is used without definition in RFC6404. So we define the term " trust
domain" as it applies to log-me marking.
1) s5.1: REQ1 - Did you mean to say "using SIP standard logging format"? Is
there another logging format other than SIP CLF?
We am not aware of any other SIP logging formats and SIP CLF is expected to be
used, but the logging format will be defined in the solutions draft.
2) s5.1: Should the must be MUST in the following:
All log retrieval mechanisms must adhere to
authorization and privacy protection policies
set forth by the network administrator.
This "must" was left lower case as retrieval itself is out of scope, but we
think
capitalizing MUST would be consistent with the rest of the draft so we
can do that. Although this MUST does not impact interoperability, we
extended the use of MUST beyond interoperability required to satisfy RFC
2119 as a result of a comment from area director Ben Campbell.
3) s5.2: REQ3 seems odd to me - Isn't this kind of like a SIP thing?
I mean if SIP doesn't allow adding new headers then didn't somebody sink
your battleship? But SIP does allow you to add arbitrary headers so I think
I'm missing something as to why this is needed?
The purpose of REQ3 is to make it clear that the solution needs a new
protocol element, i.e. "log me" marking cannot be done using existing SIP.
The text says: "REQ3: It MUST be possible to mark a SIP request or response
as of interest for logging by inserting a "log me" marker. This is known as
"log
me" marking. "
4) s5.2: REQ3 - Reads a bit awkward to me how about:
It MUST be possible to mark a SIP request or response for
logging by inserting a "log me" marker.
i.e., remove "of interest"
We can see your point. The purpose of the words "of interest" is to avoid
suggesting that marking requests and responses forces them to be logged.
The decision of whether to honour the log-me marking is largely left to the
admin policy (e.g. s6.2.1 says " The presence of a "log me" marker
might cause some SIP entities to log signaling.") but "log me" marking is not
expected to force logging in all cases.
The following revision of REQ3 would clarify:
REQ3: It MUST be possible to mark a SIP request or response to be considered
for logging by inserting a "log me" marker.
5) s5.2: REQ4 - Again this seems like a basic SIP thing - I mean are there
fields
that SIP requires be stripped?
The purpose of REQ4 (It MUST be possible for a "log me" marker to cross
network boundaries.) is to ensure that the log me marker is not defined in a
way that will very probably cause it to be removed by real-world networks
such as described earlier in the draft in s3.1 ("A network boundary is
significant in this document because manipulation of signaling at the
boundary could prevent end-to-end testing or troubleshooting. "). Also,
some protocol elements might change at a network boundary, for example
an outgoing network boundary may obfuscate some fields, or an incoming
network boundary might translate the request URI from a public identity to
one that is private to that network.
6) Is there a missing requirement based on the security considerations that
requires the this marker MUST be removed at the earliest opportunity if it
has been incorrectly inserted?
We can move the text "The presence of a "log me" marker might cause some SIP
entities to log signaling. Therefore, this marker MUST be removed at the
earliest opportunity if it has been incorrectly inserted."
from s6.2.1 and add a REQ12 in s5.3.
_______________________________________________
insipid mailing list
insipid(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/insipid