Subject: [Capwap] Issue 162: Nits from Pasi's Review

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Tue, 29 Jul 2008 10:57:53 -0700

> Section 2, 1st para: should reference RFC4347 instead of RFC4346

Correct - made the change.

> 
> Section 2.3: should have a sentence saying what transitions
represented by punctuation characters mean.

Correct - the sentence SHOULD have read:

<new text>
      The state machine transitions in Figure 4 are represented
      by alphabetic and punctuation characters.
</new text>

> 
> Section 2.4.1: "DTLS will never terminate the handshake due to
non-responsiveness; instead, DTLS will continue to 
> increase its back-off timer period" While RFC 4347 doesn't specify how
long you should continue retransmitting, the 
> intent certainly was not to continue indefinitely.
> 
> Section 2.4.3 text about DTLS retransmissions is slightly inaccurate;
DTLS handshake isn't strictly request/response, 
> and both parties (not just the DTLS client) retransmit based on timers
(in some situations).

Created issue 168 to track this.

> 
> Section 2.4.4.1: should reference RFC4346 instead of RFC4279.

Got it.

> Section 2.4.4.2: TLS_DHE_PSK_WITH_AES_256_CBC_SHA is listed twice.

Yup - cut/paste error. Got it.

> 
> Section 4.4.1, "The 8 bit Length field" looks like 16 bits.

Correct - the picture was right. Changed the text.

> 
> Section 4.4.2: is it unambiguous which 802.3 frame fields are included
or omitted? (e.g. preamble, SOF delimeter, etc.)
> 
> Section 4.6, message element 29 is spelled "Image Information"
> in the rest of the document, but "Image Info" here

Yup - thanks.

> 
> Section 4.6.1, description of R-MAC Field needs some more text
(current text would probably be fine if the field was 
> only 1 bit, but it's 8 bits).

I will create a separate issue for this, because it will require a
little more work than just a nit. Issue 163 now exists to track this and
I will take this up in a separate thread.

> 
> Section 4.6.6 (AC Timestamp): the timestamp format in RFC 1305 is
> 64 bits, but the field here is only 32 bits.

Oh, right. The intent was to only include the most significant 32 bits
of the timestamp. We are not too worried about the kind of granularity
that the lower 32 bits would provide. So in order to address this, I
would propose a small change to the text:

<new text>
   Timestamp:   The AC's current time, allowing all of the WTPs to be
      time synchronized in the format defined by Network Time Protocol
      (NTP) in RFC 1305 [RFC1305]. Only the most significant 32 bits of
      the NTP time is included in this field.
</new text>

> 
> The description of bit fields needs clarification in several places:
> at least Section 4.6.1 (Security field), 4.6.1 (DTLS Policy field),
> 4.6.43 (Frame Tunnel Mode field). For example, the "Security" field
currently seems to say that bit 1 is X.509, bit 2 
> is PSK, and bits 0 and 3..7 are unused -- but the intention was
probably to say that bit 0 is X.509 and so on. This 
> gets especially confusing in Section 4.6.43 (and associated IANA text
in 15.21), where it's not even clear whether this 
> is an enumeration or bit field. Drawing bit diagrams would be a good
idea, IMHO.

Again, because of the amount of text that will be changed due to this
Clarification, I have created issue 164.

> 
> Section 4.6.50 (WTP Static IP Address Information): probably should
have a sentence saying why this is for IPv4 only.

Well.. I have added the following sentence to the introduction of the
Message element:

<new text>
IPv6 WTPs are expected to use dynamic addresses.
</new text>

> 
> Section 4.6.50 (WTP Static IP Address Information): "Netmask" field is
listed twice.

Got it - thanks.

> 
> Section 4.6.28 (Image Identifier): length should be >= 5 (instead of
1)?

Correct

> 
> Section 4.6.30 (Initiate Download): there's no message element named
"Image Download"

You've unfortunately uncovered a much bigger issue. I have created issue
165 to track this.

> 
> Section 6.1 (Join Request): WTP IPv4/6 IP Address are listed twice.

Fixed by addressing the NAT Considerations issue.

> 
> Section 4.6.28 (Image Identifier) says this message element is sent by
the AC to the WTP; but according to Section 9.1, 
> it can also be sent by the WTP?
Yes, this is now part of issue 165

> 
> Section 9.1.2: should say that "Image Information" and "Initiate
Download" elements are included only when this message 
> is sent by the AC.
Also part of issue 165

> 
> Section 12.2 says Session ID is 64 bits, but in Section 4.6.37, it's
32 bits.

Right. Changed the Session ID message element length.

> 
> Section 12.5: This text probably needs to mention PSK Identity Hint as
well.

Not sure what this means, so will open up a new tracker issue 167 to
handle this.

> 
> Section 15: Even if the well-known port numbers have already been
allocated, it would be good to say they've been 
> allocated by IANA.
> 
> Section 15: needs to cite RFC 5226 for the "Standards Action" policy.
> 
> Section 15: RFC 5226 says that documents requesting creation of new
registries MUST include certain instructions for 
> IANA (RFC 5226 Section 4.2) -- many of the details are currently
missing.

OK, I am creating a separate issue to track all of the IANA changes.
This is tracker issue 166.
> 
> Various places: Needs a reference to RFC 3629 for UTF-8.

Yes, took care of that.

Pasi, please confirm the issues that are addressed here are OK with you.
I can then close this. I will create separate threads for the other
issues opened as a result of this one.

Thanks again for the review!

PatC
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap

---

From: Charles Clancy <[email-masked]>
Date: Tue, 29 Jul 2008 14:22:48 -0400

Pat,

 >> Section 12.5: This text probably needs to mention PSK Identity Hint
 >> as well.
 >

We should add to the first bulleted list of section 12.5:

    o  PSK Identity: Identity hint associated with the provisioned key
       (see section 2.4.4.4 for more information).

--
t. charles clancy, ph.d.                 eng.umd.edu/~tcc
electrical & computer engineering, university of maryland
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

---

From: Charles Clancy <[email-masked]>
Date: Tue, 29 Jul 2008 14:24:58 -0400

Correction -- we already have "Key Identifier" in the bulleted list, 
which is the PSK Identity Hint.  Perhaps it would be best to add the 
text I mentioned below in place of the third bullet in the first 
bulleted list of 12.5.