Thanks Ben for a thorough review. Very good comments indeed. We'll come back to this in a bit.. you know -00 deadline approaching and such ;) - Jouni On 2/29/12 1:34 AM, "ext Ben Campbell" <ben@xxxxxxxxxxx> wrote: > I am the assigned Gen-ART reviewer for this draft. For background on > Gen-ART, please see the FAQ at > < http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. > > Please wait for direction from your document shepherd > or AD before posting a new version of the draft. > > Document: draft-ietf-mext-mip6-tls-03 > Reviewer: Ben Campbell > Review Date: 2012-02-28 > IETF LC End Date: 2012-02-29 > IESG Telechat date: 2012-03-01 > > Note: Since the Telechat review deadline is a day before the end of the IETF > last call, this review serves both as a Telechat review and an IETF Last Call > review. > > Summary: This draft is basically ready for publication as an experimental RFC. > There are some clarification issues that might should be addressed prior to > publication. > > Major issues: > > None > > > Minor issues: > > -- general: > > The draft seems to be missing information on how to match TLS certificates to > identities for HAC authentication. > > -- section 1, paragraph 1, last sentence: "Client implementation experience > has shown that the use of IKE(v2)/IPsec with Mobile IPv6 is fairly complex." > > It might be worth elaborating on why this is true. Could this be solved with a > cleaner software architecture rather than a protocol change? > > -- section 5.4: "The actual domain name used in queries is up to the > deployment to decide and out of scope of this specification." > > This seems under specified for SRV > > -- 5.7.4: > > Are more than one DNS server allowed for each protocol? > > -- 5.8: > > I find this section confusing,as the first and second paragraphs seem to make > contradictory statements about the authentication, particularly about the use > of PSK. I think you are talking about authentication of the HAC in the TLS > handshake vs an higher level authentication of the MN using PSK or EAP. I > think this could use some clarification, as both paragraphs talks about > authentication between the MN and HAC without mentioning direction. > > Note that this is more clear in the security considerations section, but it > would help for it to be more clear here. > > -- 5.9, 2nd to last paragraph: > > How do the first and last sentences relate? It seems to say set it to "1", > except for this case in which you set it to "1". > > -- 8.1: > > Is this registry only for TLS based MIPv6? If so, does it need to be > explicitly constrained to not used for MIPv6 in general? > > > > > Nits/editorial comments: > > -- section 4.1: > > A picture showing the element and key relationships could be helpful here. > > -- section 4.3, third paragraph: > > Please expand BA on first mention > > --section 4.3, "Security association validity times", : "hours or weeks" > > Hours _to_ weeks? > > -- section 4.3, "selected cyphersuite": " The selected algorithms SHOULD be > one of the mutually supported ciphersuites" > > How could it be otherwise? (i.e. why the SHOULD, and is this really normative > vs descriptive?) > > -- section 4.4: "Home Agent IP Address" : "Concerns both IPv6 and IPv4 home > agent addresses." > > Dual stack only? (same applies to "Home Address" section) > > -- section 5.1, second paragraph: "All data inside the Content portion of the > message container MUST be encoded using octets." > > I suspect I'm missing a subtlety here--but how else could you do it? Is this > intended to imply a byte-field, or to imply no additional encoding is used? > > -- section 5.2: "From now on, we use TypeValue header (TV-header) term to > refer request-response message content HTTP-like headers." > > Maybe that should be moved to the terminology section? > > -- section 5.3, 2nd paragraph: "The MN is also the peer that always sends only > request messages and the HAC only sends response messages." > > I'm having trouble parsing. Is their a spurious "always"? > > -- section 5.5 : "same to that used by HTTP" > > same _as_? > > -- section 5.5.5 > > s/till/until > > -- 5.5.8, 1st sentence: > > Sentence fragment. Missing words? > > -- 5.9, first paragraph: > > Sentence fragment. > > -- 5.9, 2nd to last paragraph: > > s/"In case the"/"In the case that the" > > -- 9: > > A general discussion of threats would be helpful. Some aspects are scattered > in the subsections, but a summary in one place would be nice. > > -- 9.2: > > It's not clear to me if the text in the "Dictionary Attack" section is > actually related to dictionary attacks. > > > -- 6.1: > > A picture of the general packet format would be nice. You've got them later > for specific packet types, but no "general" picture. > > --6.2: > > Section seems mostly redundant to 6.1 > > -- 6.3: > > Please expand HoTI on first use. > > -- 7: > > Please expand CoTI/CoT on first use > > -- 8.3: > > I'm not sure I understand the mnemonic relevance of "HALTSEC" > > > > > _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf