Subject: Re: [Gen-art] [kitten] Genart telechat review of draft-ietf-kitten-rfc5653bis-06

From: Weijun Wang <[email-masked]>
Date: Tue, 6 Feb 2018 22:17:35 +0800

I will submit a new draft tomorrow if there is no other feedback.

Thanks
Weijun

> On Jan 29, 2018, at 9:26 AM, Weijun Wang <[email-masked]> wrote:
> 
> The HTML file updated in place.
> 
> Thanks
> Weijun
> 
>> On Jan 27, 2018, at 10:12 AM, Greg Hudson <[email-masked]> wrote:
>> 
>> On 01/23/2018 06:43 PM, Weijun Wang wrote:
>>> I've uploaded an updated version at
>>> 
>>> http://cr.openjdk.java.net/~weijun/rfc5653bis/draft-ietf-kitten-rfc5653bis-07.html
>> 
>> This is a great format for reviewing these changes; thanks for
>> generating it.
>> 
>> Line 416 does not capitalize "optional" in "optional services", but
>> lines 385 and 391 do.
>> 
>> Lines 422 and 424 should probably capitalize "should".  Line 429 should
>> probably capitalize "may".
>> 
>> At line 598, I would lean towards leaving "MUST" in lowercase as we are
>> describing an application requirement, not prescribing one.
>> 
>> Line 1174, I would leave "MAY" in lowercase.
>> 
>> Line 1229, "may" should probably be capitalized.
>> 
>> Line 1369, I would leave "MAY" alone as this seems more descriptive than
>> prescriptive.
>> 
>> Line 3221's use of "SHOULD" is prescriptive, but there's no other way to
>> request the default QOP.  So I would leave it lowercase (or change the
>> wording, but I'm not trying to open any more cans of worms).
>> 
> 
> _______________________________________________
> Kitten mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/kitten

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 7 Feb 2018 11:35:34 -0600

I am doing a review now.  (Line 413, "SHOULD not" --> "SHOULD NOT"
is all I have so far.)

And I will second Greg's comment about this format being an awesome
way to view these changes -- thank you again for putting them
together!

-Ben

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 7 Feb 2018 15:32:48 -0600

And the rest of the review:

Line 2519, I think should --> SHOULD, since elsewhere we use SHOULD
for sending the error token to the peer.

Line 2561, I could go either way on "may" vs. "MAY" -- the argument
for the former would be that it's just stating an attribute of the
operation, and this text is describing something specified elsewhere
and not introducing any restrictions or giving guidance on it.
Similarly for acceptSecContext on line 2597.

Line 2668, SHOULD not --> SHOULD NOT

Line 2858, MAY --> may, since this is just describing what some
implementations could be doing and not exactly granting permission
for it.

I guess for consistency I should say the same thing about line 3049.

Line 3716, MUST not --> MUST NOT

In general, things looked quite good; I do not think I can say thank
you enough for putting this together.

Greg, would you be able to sanity-check the above (and one below)
comment?

Thanks,

Ben

---

From: Greg Hudson <[email-masked]>
Date: Wed, 7 Feb 2018 17:43:58 -0500

On 02/07/2018 04:32 PM, Benjamin Kaduk wrote:> Line 2519, I think should
--> SHOULD, since elsewhere we use SHOULD
> for sending the error token to the peer.

No opinion.  You could make a case for "that should be sent" being
either descriptive on the token or prescriptive on the application.

> Similarly for acceptSecContext on line 2597.

I think that's a MAY.  It seems prescriptive on the method implementation.

> Line 2668, SHOULD not --> SHOULD NOT

Agree.

> implementations could be doing and not exactly granting permission

Sure, and it's an example.

> I guess for consistency I should say the same thing about line 3049.

I guess "may" here, but no strong opinion.

> Line 3716, MUST not --> MUST NOT

Agree.

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 7 Feb 2018 16:57:56 -0600

> On 02/07/2018 04:32 PM, Benjamin Kaduk wrote:> Line 2519, I think should
[line 2519]
> either descriptive on the token or prescriptive on the application.

Re-reading, I agree with you and retract the suggestion.

> I think that's a MAY.  It seems prescriptive on the method implementation.

Okay.

> > Line 3716, MUST not --> MUST NOT

Thanks for double-checking my work.

-Ben

---

From: Weijun Wang <[email-masked]>
Date: Thu, 8 Feb 2018 11:36:23 +0800

Thanks a lot. I finally make 3 s/not/NOT/ and 2 s/MAY/may/.

@@ -410,7 +410,7 @@
       of sequence.
 
       Anonymous Authentication: The establishment of the security
-      context SHOULD not reveal the initiator's identity to the context
+      context SHOULD NOT reveal the initiator's identity to the context
       acceptor.
 
    Some mechanisms may not support all OPTIONAL services, and some
@@ -2665,7 +2665,7 @@
    ability may depend on the availability of system resources at the
    time that wrap is called.  However, if the implementation itself
    imposes an upper limit on the length of messages that may be
-   processed by wrap, the implementation SHOULD not return a value that
+   processed by wrap, the implementation SHOULD NOT return a value that
    is greater than this length.
 
    Parameters:
@@ -2855,7 +2855,7 @@
    The implementation MAY constrain the set of processes by which the
    inter-process token may be imported, either as a function of local
    security policy, or as a result of implementation decisions.  For
-   example, some implementations MAY constrain contexts to be passed
+   example, some implementations may constrain contexts to be passed
    only between processes that run under the same account, or which are
    part of the same process group.
 
@@ -3046,7 +3046,7 @@
    public boolean isProtReady()
 
    Returns "true" if the per-message operations can be applied over the
-   context.  Some mechanisms MAY allow the usage of per-message
+   context.  Some mechanisms may allow the usage of per-message
    operations before the context is fully established.  This will also
    indicate that the get methods will return actual context state
    characteristics instead of the desired ones.
@@ -3713,7 +3713,7 @@
 
    outputToken         The output token that SHOULD be sent to the peer.
                        Can be null if no such token is available.  It
-                       MUST not be an empty array.  When provided, the
+                       MUST NOT be an empty array.  When provided, the
                        array will be cloned to protect against
                        subsequent modifications.

Thanks
Weijun

> On Feb 8, 2018, at 6:57 AM, Benjamin Kaduk <[email-masked]> wrote:
>

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 8 Feb 2018 16:32:40 -0600

> Thanks a lot. I finally make 3 s/not/NOT/ and 2 s/MAY/may/.

Great!

I think that once you submit the new revision, it's up to Ekr to
verify that the diff addresses the point raised by Alissa/Joel and
then inform the secretariat that the document is approved.

Thanks again,

Ben

---

From: Weijun Wang <[email-masked]>
Date: Fri, 9 Feb 2018 09:31:59 +0800

https://tools.ietf.org/html/draft-ietf-kitten-rfc5653bis-07 posted.

Thanks
Weijun

> On Feb 9, 2018, at 6:32 AM, Benjamin Kaduk <[email-masked]> wrote:
>