Subject: [Gen-art] Gen-ART review of draft-ietf-crisp-iris-lwz-07

From: Spencer Dawkins <[email-masked]>
Date: Wed, 24 Jan 2007 11:02:41 -0600

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 wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-ietf-crisp-iris-lwz-07
Reviewer: Spencer Dawkins
Review Date:  24 January 2007
IESG Telechat date: 25 January 2007

Summary: This document is almost ready for publication as a Proposed 
Standard. I am not happy about two SHOULDs, which I mention in a re-review 
because both involve new text.

Comments:

My previous review (of -06) is at 
http://www.alvestrand.no/ietf/gen/reviews/draft-ietf-crisp-iris-lwz-06-dawkins.txt. 
The biggest issues I raised then have been addressed.

This document could be published as-is. I think the specification could 
easily be improved in two ways.

- Sequential Transaction IDs are still SHOULD NOT in 3.1.1, but the updated 
Section 8 now justifies SHOULD and adds a new MUST for implementers who are 
violating the SHOULD NOT. I'm not asking for 3.1.1 to be MUST NOT, but I'm 
really curious why the requirement isn't "MUST NOT be sequential", and I 
don't see any explanation about why MUST NOT was not chosen.

- New text in Section 4 defines retransmission behavior, but initial RTO of 
one second and subsequent RTO doubling is SHOULD, not MUST, with no 
explanation about why an implementor might choose to violate the SHOULD. I'd 
love to know why this protocol is "special" - any TCP-based application 
protocol would be doing something like what this protocol has as a SHOULD...

Thanks,

Spencer

_______________________________________________
Gen-art mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/gen-art

---

From: Andrew Newton <[email-masked]>
Date: Wed, 24 Jan 2007 12:14:17 -0500

On Jan 24, 2007, at 12:02 PM, Spencer Dawkins wrote:
> - Sequential Transaction IDs are still SHOULD NOT in 3.1.1, but the  
> updated Section 8 now justifies SHOULD and adds a new MUST for  
> implementers who are violating the SHOULD NOT. I'm not asking for  
> 3.1.1 to be MUST NOT, but I'm really curious why the requirement  
> isn't "MUST NOT be sequential", and I don't see any explanation  
> about why MUST NOT was not chosen.

If an implementation does pick sequential numbers (i.e. violates the  
SHOULD), they will still be able to interoperate.  If they break this  
rule, they ought to know what they are doing and the consequences for  
it.  Informing implementers that running with scissors is a good  
thing, legislating against it is not.

> - New text in Section 4 defines retransmission behavior, but  
> initial RTO of one second and subsequent RTO doubling is SHOULD,  
> not MUST, with no explanation about why an implementor might choose  
> to violate the SHOULD. I'd love to know why this protocol is  
> "special" - any TCP-based application protocol would be doing  
> something like what this protocol has as a SHOULD...

Essentially, the same argument applies here.  Though I will admit  
that a violation of this SHOULD might have consequences on others.

-andy