On 17 Aug 2016, at 17:04, Joel M. Halpern wrote:
Making sure I understand what is being asked in each of these items,
hence in-line.
Yours,
Joel
On 8/17/16 5:11 PM, Ben Campbell wrote:
[...]
----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------
In section 3.4, the text says that the requirements that the
integrity
protection mechanisms can actually provide integrity protection are
SHOULD because some communication may occur over non-secure channels.
That does not follow, since the rationale is about use, while the
actual
requirement is about capability. As currently written, it leaves it
possible for people to select a protocol that cannot provide
integrity
protection at all. I think the SHOULDs in 14 and 15 need to be MUSTS.
I think what you are asking is that we rephrase these requirements to
indicate that implementations must include integrity protection
capability which meets these requirements. And that the current text
explaining the SHOULD becomes text about when these mechanisms SHOULD
be used?
Yes.
In the third paragaph of 3.2, Isn't the point to say that ephemeral
data
MUST be sent over a secure transport unless the data model explicitly
labels it as safe for insecure transports? As written, it seems to
leave
room to send data that is not labeled as safe to also be sent over
insecure transports.
I am having trouble seeing the problem. The text, as far as I can
tell, says "SHOULD be protect", and then goes on to say "except when
the model says it is okay to send unprotected". That seems to say the
right thing.
I take "SHOULD except..." to mean something fundamentally different than
"MUST except..." SHOULD allows the implementers (or I guess protocol
designers in this case) the additional flexibility of deciding they have
some other good reason to deviate from the guidance, in addition to
whatever might be list. Is that the intent here?
----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------
-2.1: I am on the fence about other's comments about copying
definitions
here--but if you do copy them here, it seems strange to not mention
"client" or "agent".
I can live with just listing the terms and references, without the
text. It makes reading a little more complex for new readers, but
avoids any risk of error in copying.
I think that's a good answer to other people's comments :-) My comment
was, _if_ this draft continues to mention the defined terms, it would be
good to also mention client and agent.
I agree with Alissa about equating privacy and confidentiality.
I was going to simply say "sure", but REQ-20 sems to need to still say
"privacy". Not sure what you (individually or collectively) would
like us to do.
I do note that if the terminology has shifted from that documented in
4949, it would be helpful to those of us who do not live with it daily
to have some way to know such.
It probably makes sense to keep this discussion in the thread from
Alissa's comments.
-3.1,:
I’m confused by the first paragraph. I don’t find strings of the
form of
SEC-REQ-XX in 7921. I think _this_ doc sets these requirements,
right?
Section 3.1 is trying to recapitulate for context requirements that
are stated in textual form in RFC 7921. No, they are not lsited as
SEQ_REQ-XX or even REQ-XX in RFC 7921. Thus, in addition to context,
listing them here allows us to give them numbers for consistency of
discussion. (Thus, this is a case where repetition adds value.)
It think some clarification text would be in order. (I am agnostic about
Mirja's and Alissa's comments about whether these should be replicated
at all.)
It’s not clear to me how 5 and 6 differ. Is it just a matter of the
additional “before establishing a connection” part in 6?
As far as I know, it is indeed just a matter of the timing being added
in 6. If this is a problem, we can collapse them.
I'm okay either way on this one.
-3.4: Isn't 15 simply a restatement of the third item under 14?
that looks like an error on our part. Maybe I missed something, but I
think we can drop that when we rewrite to address your major comment.
Okay. The odd part is that 15 seems to recognize that it's just a
restatement :-)
3.5: The MAYs in 19 and 20 seem like statements of fact. (That is,
do
they simply recognize reality, or to they grant permission?)
Re-reading these, the MAY in 19 is a description of allowed
architecture, and seems to me to wall within the 2119 meaning.
Is the MAY in 19 a materially new statement, or is that already covered
in the architecture? If the latter, something to the effect of "The
architecture allows..." might make more sense.
The may in 20 is subtler. I think it is recognizing reality, since
that mechanism is not something we are going to be defining, as far as
I know. It can be argued that it is saying that these requirements
allow such a range of mechanism. But I agree that 2119 usage is a bit
of a stretch there.
_______________________________________________
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs
_______________________________________________
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs
