Re: Gen-ART LC Review of draft-ietf-netext-bulk-re-registration-09</= TITLE> </HEAD> <BODY> Hi Chris, Thanks for the review. These terms are from RFC-5213. The spec did point to the base specs. But, w= ill ensure we add the references to those terms at first usage. I’ll n= ote this comment. Regards Sri On 1/16/12 6:14 AM, "Christer Holmberg" <<a href=3D"christer.hol= mberg@ericsson.com">christer.holmberg@ericsson.com</a>> wrote: <BLOCKQUOTE>I am the assigned Gen-ART reviewer for this draft. For background on Ge= n-ART, please see the FAQ at <<a href=3D"http://wi= ki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq">http://wiki.tools.ietf.org/a= rea/gen/trac/wiki/GenArtfaq</a> <<a href=3D"http://wiki.tools.ie= tf.org/area/gen/trac/wiki/GenArtfaq">http://wiki.tools.ietf.org/area/gen/tra= c/wiki/GenArtfaq</a>> >. Please wait for direction from your document shepherd or AD before posting = a new version of the draft. Document: draft-ietf-netext-bulk-re-registration-09 Reviewer: Christer Holmberg Review Date: 16 January 2012 IETF LC End Date: 17 January 2012 IESG Telechat date: 19 January 2012 Summary: This draft is basically ready for publication, but has nits that s= hould be fixed before publication. Major issues: - Minor issues: - Nits/editorial comments: - The document talks about mobile access gateways and local mobility anchor= s, but I did not find any references to, and/or definitions of, those. Regards, Christer </BLOCKQUOTE> </BODY> </HTML> --B_3409547755_42844521-- From dino@cisco.com Mon Jan 16 11:50:45 2012 Return-Path: <dino@cisco.com> X-Original-To: gen-art@ietfa.amsl.com Delivered-To: gen-art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AE1D21F86A9 for <gen-art@ietfa.amsl.com>; Mon, 16 Jan 2012 11:50:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=x tagged_above=-999 required=5 tests=[] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gZOMqTv7fic5 for <gen-art@ietfa.amsl.com>; Mon, 16 Jan 2012 11:50:44 -0800 (PST) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 8B7B221F86A8 for <gen-art@ietf.org>; Mon, 16 Jan 2012 11:50:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dino@cisco.com; l=454667; q=dns/txt; s=iport; t=1326743444; x=1327953044; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=SB5JJ7J0wC73PzWyWdg3G5eELBYFvFbDQz+QAedC84w=; b=m89uU8Hp2c9ERtBj9cQGDGRfWLgcrKc+hXNWgzIQ48mwVVf5/mX8hCzZ gYPbEhpXRAazADTn40yhe0dE7yHkw0nOFkBMTza/wENJeAqSZVoQUcVkU RHONOGj5KHL84wX8PyNvrekZbvFdlz8EH4g81QOQ/Vt1KhfK4W1DHEh2h 8=; X-Files: rfcdiff-ietf-lisp-19-to-20.html, draft-ietf-lisp-20.txt : 218806, 215512 X-IronPort-AV: E=Sophos;i="4.71,519,1320624000"; d="txt'?html'217?scan'217,208,217";a="25500432" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-4.cisco.com with ESMTP; 16 Jan 2012 19:50:43 +0000 Received: from sjc-vpn7-1248.cisco.com (sjc-vpn7-1248.cisco.com [10.21.148.224]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q0GJogHE012573; Mon, 16 Jan 2012 19:50:42 GMT Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: multipart/mixed; boundary="Apple-Mail=_35E221EE-EA9A-40C6-9190-D01655B17C04" From: Dino Farinacci <dino@cisco.com> In-Reply-To: <1326652051.4790.1231.camel@mightyatom.folly.org.uk> Date: Mon, 16 Jan 2012 11:50:42 -0800 Message-Id: <1413A7D9-03E0-4746-AE07-21BA75469269@cisco.com> References: <1326652051.4790.1231.camel@mightyatom.folly.org.uk> To: Elwyn Davies <elwynd@dial.pipex.com> X-Mailer: Apple Mail (2.1251.1) X-Mailman-Approved-At: Mon, 16 Jan 2012 11:54:01 -0800 Cc: gen-art@ietf.org, Terry Manderson <terry.manderson@icann.org>, Joel Halpern <joel.halpern@ericsson.com>, draft-ietf-lisp.all@tools.ietf.org Subject: Re: [Gen-art] Gen-art telechat review - draft-ietf-lisp-19.txt X-BeenThere: gen-art@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/gen-art> List-Post: <mailto:gen-art@ietf.org> List-Help: <mailto:gen-art-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 16 Jan 2012 19:50:45 -0000 --Apple-Mail=_35E221EE-EA9A-40C6-9190-D01655B17C04 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > 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>. >=20 > Please wait for direction from your document shepherd > or AD before posting a new version of the draft. >=20 > Document: draft-ietf-lisp-19.txt > Reviewer: Elwyn Davies > Review Date: 20120115 > IETF LC End Date: 20111130 > IESG Telechat date: 20120119 >=20 > Summary: This is an updated version of the review I did for Version = 16. > The status is STILL 'almost ready'. I noticed one additional minor = issue > (s3, ITRs). I did not receive any explicit reponses to the comments in > the previous review although some of the comments have been addressed > and I have removed those comments. So... >=20 > Given that this document is experimental, there don't appear to be any > showstopping issues. However, I found that having the functionality > spread over several documents without a really clear overview did not > make it easy to follow. There are a number of areas where topics = appear > unannounced in ways that are not immediately meaningful, and may or = may > not be clarified later in the document (especially the topics of > multicast and anycast). >=20 > There are areas of the detailed format description that are very dense=20= > and difficult to follow, and the split of functionality between this=20= > document and ALT does not help. I got the distinct feeling that extra=20= > bits of functionality had been shoe horned into this section over time=20= > without really thinking through the system aspects. However given = that=20 > we are considering an experimental protocol this is not a major issue,=20= > provided that it is cleaned up before becoming a real standard. >=20 > Major issues: None. This is good to know. Thanks for your comments Elwyn. See responses = below. I have a new -20 diff file enclosed to make sure I reflected your = comments. Please have a look and comment as soon as you can. Thanks. > Minor issues: > s3, Ingress Tunnel Router (ITR): "An ITR is a router which accepts an = IP > packet with a single IP header": Technically this rules out a site > attached to an ITR using any form of IP tunneling (such as VPNs or IP > mobility or 6-in-4 tunnels) through the ITR because a tunneled packet > would already have more than one IP header. In practice, I think the > qualifying statement in brackets immediately after the quoted = statement > clarifies the situation but this should be rewrittten to avoid > ambiguity. Fixed. > s3, EID: "EIDs MUST NOT be used as RLOCs": But the remainder of the > definition goes on to talk about what must/must not happen when they = are > numerically equivalent. This is still somewhat confusing. When they are numerically equivaldent does not mean they are the same = definition. Remember there are two namespaces so 10.1.1.1 in one = namespace serves a different purpose than 10.1.1.1 in the other = namespace. I made no change here because we revised this definition dozens of times = to make the working group happy. So this definition is rough concensus. > s3, Data Probe: Some clarification/explanation is needed regarding the=20= > fact that a Data Probe uses an EID as its destination address in the=20= > core, but EIDs are specifically described as not routable in the core=20= > earlier in the document. I understand that ALT puts caveats on the=20 > usability of Data Probes, but still potentially offers routability of=20= > the EID over the alternative topology. I think some reflection of = this=20 > discussion would be helpful here. I added to the definition that when Data Probes are used, the underlying = routing system must advertise EIDs. This is not desirable but there are = rare cases, it may be used. > s4.1, item 4: ETR "processes as a control message"... does this imply=20= > anything about prioritization in the rest of the network? No different than anything else and doesn't deserve a mention in my = opinion. > s5.3, LISP Nonce: What are the consequences of using the same nonce = for=20 > 'too long'.. and how can an implementor decide what is too long? A possible replay attack if a man-in-the-middle can guess a 24-bit or = 128-bit nonce. > s6.1: "Implementations MUST be prepared to accept packets when either = the > source port or destination UDP port is set to 4342 due to NATs > changing port number values." I (still) don't understand this. My=20= > understanding was that these UDP packets are generated in the ITR with=20= > globally routable RLOCs in the headers. Why are they going through = NATs? > Does this mean when only one of the ports is 4342? (but the previous > comments still stands). An ITR could be behind a NAT. And when it is its "local RLOC" is a = private address. When the packet traverses a NAT, the source address = will be changed to a global address. The outside world believes the = source of the packet is the source RLOC which is globally reachable and = advertised in the underlying routing system. NATs also translate/change the source port of the outer header. So the = if a LISP control packet is returning a reply to a request that had 4342 = in the destination port, then the source port would be translated and = the requester would not know the packet is a LISP control packet. So if = the source port of the request is 4342, the replier can return that in = the destination port of the reply without a NAT touching the port (while = it is touching the other port). > s5.3: Copying of TTL/Hop Count fields and Type of service fields: This=20= > discussion is somewhat confusing. Initially these are described as=20 > SHOULD mostly without any description of why one would not. A couple = of=20 > paragraphs later they become MUSTs with some minor and explicit=20 > exceptions. This should be clarified. We said should because we were being practical. Some implementations = cannot copy the TTL and set it statically. We want those implementations = to not violate the spec. We use MUST later for the Type of Service field. When the TOS is copied, = then the sub-parts MUST follow what the text says. > s6.1, last para: "This main LISP specification is the authoritative=20 > source for message > format definitions for the Map-Request and Map-Reply messages." So=20= > what spec is authoritative for Map-Register and Map-Notify? It is = later=20 > stated that this spec defines the message format of these messages=20 > (first paras of s6.1.6/6.1.7). This seems pretty authoritative. I=20 > suspect that this para could be dropped wlog. I will fix this text. Thanks for finding this. > s6.1.4: S bit: How do I find out how big the Mapping Protocol Data is = in=20 > order to determine where the extra security fields are located? This was commented on quite a bit and was used for CONS. Since the = commenters won the argument to remove references to CONS, we will remove = the Mapping Protocol Data part, which actually is not used by any = implementations. > s6.1.4: M priority/weight: Multicast suddenly makes an appearance. = Not=20 > sure why? Because we have to encode multicast priorities. And to get a mapping for = an ETR to join an ITR, we use a Map-Request/Map-Reply exchange. I will = add a reference to LISP-multicast for each reference to M priority and M = weight. > s10.3: How is a "route-returnability check" performed in LISP? I added another sentence to the defintion of "Route-returnability". > Nits/editorial comments: > General: s/bytes/octets/ Changed throughout. > General: Figures all need titles and numbers. There are section titles for the figures. There are no figure numbers = just like RFC 2460. I don't see the point since there is no text that = back references the figures. And I think we wrote the text to = sufficiently introduce the figures that are about to come up. > s3: s/PA addresses are an an address/PA addresses are an address/ >=20 > s3, RLOC: Link to IPv4/v6 specifications needed. >=20 > s3, EID-to-RLOC Database: "This has no negative implications."=20 > Justification? >=20 > s3, Negative Mapping Entry: Needs cross-reference for Negative = Map-Reply. Changed all the above. > s3, Data Probe: needs cross-reference(s) I don't think it does because it is being defined here for the first = time. > s3, PITR: The alternative term PTR is now not used at all and can be > removed. Fixed. > s4.1, item 7: Needs cross references. Can you be more specific please. Are you asking for a reference for DNS = names or for the Map-Reply or for something else? > s5.1 and s5.2 Need references to base IP specifications and notes = about=20 > the items that are defined in those specifications, and the = equivalences=20 > between source/destination IP addresses and EIDs/RLOCs. (also applies = to=20 > s6.1) We did this in a later update. We put the references in 5.3 where we = describe such fields. > s5.3: This section should also refer to the various abbreviations used=20= > in the figures (e.g., OH for Outer Header, etc). It is expanded in the "Packet header descriptions:" part. > s5.3, LSB: First mention of anycast addresses here. Needs a cross=20 > reference or earlier introduction. I have added a definition for anycast address in the Definition of Terms = section. > s6.x: Encodings of numeric fields not specified. All fixed. New text enclosed. Please acknowledge. The -20 has not been = posted. This is a work in progress -20 waiting Adrian's comments as = well. Dino --Apple-Mail=_35E221EE-EA9A-40C6-9190-D01655B17C04 Content-Disposition: attachment; filename=rfcdiff-ietf-lisp-19-to-20.html Content-Type: text/html; name="rfcdiff-ietf-lisp-19-to-20.html" Content-Transfer-Encoding: 7bit  <html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>wdiff draft-ietf-lisp-19.txt draft-ietf-lisp-20.txt

Hi Kathleen,

Thanks for your revi= ew. We'll pick up these editorial changes as RFC Editor notes.=

Thanks again,=

Jerry

From:= "kathleen.moriarty@emc.com" <kathleen.moriarty@emc.com>To: gen-art@ietf.org; iet= f@ietf.org; draft-ash-gcac-algorithm-spec.all@tools.ietf.org
Cc: gash5107@yahoo.com; dave.mcdysan@= verizon.com
Sent: Wedne= sday, January 4, 2012 11:03 AM
Subj= ect: Gen-ART review of draft-ash-gcac-algorithm-spec-03.txt
<= /FONT>
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.iet= f.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these com= ments along with any other Last Call comments
you may receive.

Do= cument: draft-ash-gcac-algorithm-spec-03.txt
Reviewer: Kathleen M. Moria= rty
Review Date: 1/4/12
IETF LC End Date: 1/11/12
IESG Telechat da= te: 1/19/12

Summary: The draft is essentially ready with nits.= The last nit could be a minor issue, but has a simple resolution.&nb= sp; The security considerations section points out possible attacks and sho= uld also require logging of events tied to the users/groups responsible for= those actions.

Major issues:

Minor issues:

Nits/edito= rial comments:
The last line of the abstract should be on the previous l= ine.

On the second to last paragraph of page 8, the following acronym is listed: emergency traffic (ETS), should there be something for = the "S"?
The second to last sentence of the same paragraph:
Consider = changing from:
"Several
assured forwarding (AF) queues may be = used for various data traffic,
for example, premium private data = traffic, premium public data
traffic, and a separate best-effort = queue is used for the best-effort
traffic."
To: "Several
&n= bsp; assured forwarding (AF) queues may be used for various data traffic, for example, premium private data traffic, premium public data
= traffic, and a separate best-effort queue for the best-effort
&nb= sp; traffic."

First paragraph of section 3: Consider removing "howev= er", it doesn't add anything:
Change from: "Requiring nodes to expose de= tailed and
up-to-date CAC information, however, may result in una= cceptably high
rate of routing updates."
To: "Requiring nodes to expose detailed and
up-to-date CAC information may resu= lt in unacceptably high
rate of routing updates."

Second p= aragraph of Section 3: Consider removing "and cannot" - it is unnecessary:<= BR>Change from: "This common
interpretation is in the form of an = MPLS GCAC algorithm to be
performed during MPLS LSP path selectio= n to determine if a link or
node can or cannot be included for co= nsideration."
To: "This common
interpretation is in the form o= f an MPLS GCAC algorithm to be
performed during MPLS LSP path sel= ection to determine if a link or
node can be included for conside= ration."

Section 3.2: Consider breaking the first sentence into two:=
"The assumption behind the MPLS GCAC is that the ratio between BWMck, which represents the safety margin the node is putting above the SBWck, and the standard deviation of the SBWck defined below does not
change significantly as one new aggregate flow is= added on the link."

Security Considerations:
I think a requireme= nt for logging should be specified here as well. If an attack were to= occur, you will want the user/group and actions taken to be logged to trac= e the attack. Without this, the other enforcement mechanisms are inad= equate.

Sentence that spans page 17-18 should be broken into multipl= e sentences (readable, but long - as is the following sentence):
"For example, if aggregate flow requests are made for CT LSP bandwidth that exceeds the current DSTE tunnel bandwidth allocation, the GEF=
initiates a bandwidth modification request on the appropriate LS= P(s),
which may entail increasing the current LSP bandwidth alloc= ation by a
discrete increment of bandwidth denoted here as DBW, w= here DBW is the
additional amount needed by the current aggregate flow request."

There is an extra line in the second line = of A.1.

Thanks,
Kathleen

---2119685684-1575650744-1325789515=:13158-- From ben@nostrum.com Thu Jan 5 14:32:48 2012 Return-Path: X-Original-To: gen-art@ietfa.amsl.com Delivered-To: gen-art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5609921F88CE; Thu, 5 Jan 2012 14:32:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jaqhfyuKWzow; Thu, 5 Jan 2012 14:32:47 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id A0B6B21F88B1; Thu, 5 Jan 2012 14:32:45 -0800 (PST) Received: from [10.0.1.2] (cpe-76-187-92-156.tx.res.rr.com [76.187.92.156]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q05MWiLP071831 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 5 Jan 2012 16:32:45 -0600 (CST) (envelope-from ben@nostrum.com) From: Ben Campbell Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Date: Thu, 5 Jan 2012 16:32:44 -0600 Message-Id: <3D6A7926-001A-409D-BC01-B45AD8C68AEC@nostrum.com> To: draft-ietf-kitten-sasl-saml.all@tools.ietf.org Mime-Version: 1.0 (Apple Message framework v1251.1) X-Mailer: Apple Mail (2.1251.1) Received-SPF: pass (nostrum.com: 76.187.92.156 is authenticated by a trusted mechanism) Cc: "gen-art@ietf.org Review Team" , The IETF Subject: [Gen-art] Gen-ART LC Review of draft-ietf-kitten-sasl-saml-06 X-BeenThere: gen-art@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "GEN-ART: General Area Review Team" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 22:32:48 -0000 I am the assigned Gen-ART reviewer for this draft. For background on = Gen-ART, please see the FAQ at = . Please resolve these comments along with any other Last Call comments = you may receive. Document: draft-ietf-kitten-sasl-saml-06 Reviewer: Ben Campbell Review Date: 2012-01-05 IETF LC End Date:2012-01-05 IESG Telechat date: (if known) Summary: This draft is on the right track for publication as a proposed = standard. However, there are a few minor issues, and sufficient = editorial issues to make the document difficult to understand.=20 *** I noticed shortly before sending this that the authors submitted = version 07 today. I have not reviewed that version--this review refers = to version 06. Major issues: None Minor issues: -- section 3.2, last paragraph: "=85 needs to correlate the TCP session = from the SASL client with the SAML authentication." Please elaborate on this correlation -- section 4, 2nd paragraph: "The SAML Idenity Provider does not have a = role in GSS-API, and is considered an internal matter for the OpenID = mechanism." Please elaborate, as this is the only mention of OpenID in the draft. It = seems out of context. (If OpenID was in fact intended, please include a = citation?) -- section 4, 3rd and 4th paragraph (paragraph a and b) These seem like protocol affecting differences. If so, they need = elaboration, such as normative statements and formal definitions, or = references to such. -- section 5, general: The section seems to need further elaboration or references -- section 6.1, step 5 (alt) Please describe the circumstances where the alternative step would = occur. (also, please spell out "alternative")=20 -- section 6.1, step 6: "The client now sends the URL to a browser for = processing." Isn't that a question of software design rather than protocol? (unless = you mean something more abstract by "browser", in which case it would = help to say so.) Also, this section compresses the interaction with the identity = provider. Why not show the details for those steps like the others? (If = you mean them to be out of scope, then why give as much detail as you = do?) -- section 6.2: The draft does not provide the decoding of the Base64 encoded parts like = it did in 6.1, Without the decodes, the example is not very = illuminating. -- section 7.4: "This is an option the user has to understand and decide = to use if the IdP is supporting it." I doubt end users will read this spec. What does this mean for = implementors? Nits/editorial comments: -- General: There are a lot of editorial and organizational issues, some of which = created difficulty in understanding the authors' intent. I noted a = number of these below, but I doubt I caught everything. I suggest this = draft have another detailed proofreading and editing pass before it = progresses. -- Pagination is strange throughout the document. (Mostly blank pages, = etc.) It's worse in the PDF version, but still not right in the text = version. -- section 1.1, 2nd paragraph: Repeating the SAML 2.0 citation here would be helpful. -- section 1.2, 1st paragraph The sentence structure makes it ambiguous whether the other side of the = or should be just certificate validation, or TLS with cert validation.=20= -- section 2, list starting in 2nd paragraph: Please leave a blank line between list items. Without it, you get a = wall-of-text effect that's difficult to read. -- section 2, list item 3: Is "service provider" a well defined term as used here? -- section 2, paragraph after 1st numbered list: "This will be discussed = below. The steps are shown from below:" Redundant sentences. Also, I assume the discussion has already been = written, so "will be" is not correct. -- section 2, 2nd paragraph after 2nd numbered list: "=85 flow appears = as follows:" Please explicitly mention the figure number. E.g. "=85 flow appears as = shown in Figure XX." -- section 2, figure 2: The numbers in parentheses are confusing. We just saw a numbered list = that sort of corresponds to this flow, but the numbers don't match up. I = realize later sections refer back to these numbers, but without some = mention of that, a reader is almost certainly going to try to correlate = this to the previous list. -- section 3, 1st paragraph: "Recall section 5 of [RFC4422] for what = needs to be described here." That reads like an author's "to do" note to himself. Has the needed = description been completed, or does it still need to be described? -- section 3, 2nd paragraph: "The name of this mechanism "SAML20"." Missing word? -- "(via "gs2-header")" Missing word? -- section 3, 3rd paragraph: "The first mechanism message from the = client to the server is the "initial-response" described below." Please explicitly mention section.=20 -- section 3, 4th paragraph: "The second mechanism message is from the = server to the client, the "authentication- request" described below." I can't parse this sentence--are there missing words? Also, please = mention section instead of saying "below". -- section 3.1, first paragraph: Is "authorization identifier" the same as "IdP-Identifier"? -- section 3.1, ABNF Is this the authoritative definition for "initial-response"? If so, = please mention that in the text. The including section does not mention = "initial-response" -- section 3.1, last paragraph: Used as follows where, the rest of this paragraph? If so, then the "used = as follows" clause is redundant. Also, the paragraph would be much = easier to read if you broke it into a bulleted list. The 3rd sentence is awkward. I suggest something like "The =85 field is = used as described in section 5." Is there a word missing from the forth sentence?=20 -- section 3.2, 1st paragraph: s/ (re)directs/ redirects . Also, what gets redirected (i.e. what is the = direct object of "redirects"?) -- section 3.2, 3rd paragraph (2nd note) I can't parse this. -- section 3.2, BNF Is this the formal definition of authentication-request? The next = paragraph suggests it is defined in a referenced document. If so, then = the repeated definition creates confusion about which document is = authoritative on the matter. (if the definition is repeated here as a = courtesy, please say so explicitly) -- section 3.2, 6th paragraph: "The client now sends=85" s/now/then. Also, It seems like these sections jump back and forth = between message definitions and a sequence of steps. I find that = confusing. It would be better to keep the "sequence of steps" and the = "message definitions" separate. But if you want each section to = represent one or more steps in a sequence, then please add some context = (e.g. "Once the widget completes the steps in section XXX, it then =85" = ). Keep in mind readers often jump directly to a section from the table = of contents. -- section 3.3, 2nd paragraph: "and SHALL be used to set state in the = server accordingly, and it shall be used by the server" Is this new normative language, or a repeat of language from the SAML = spec? -- section 4, 1st paragraph: I have difficulty parsing this. -- section 4, 2nd paragraph, final sentence: sentence fragment. -- section 5, 1st sentence: 'The "gs2-cb-flag" MUST use "n" ' =85 MUST be set to "n"? (Or even better, 'the [actor] MUST set the = [flag] to "n" ' -- section 7 " This section will address=85" Addresses ( unless you haven't addressed it yet) Also, does the GSS-API description introduce security considerations? If = not, please say so. -- section 7.1, "=85 unless a client always verify the server identity=85 = " s/verify/verifies -- section 7.3: "SASL servers should be aware that SAML IdPs will track = - to some extent - user access to their services." I'm not sure what it means for a server to be aware of this sort of = thing. You are talking about people, not servers, right? What actions do = you propose implementors take to mitigate this? -- section 7.4: s/you/users "By using the same identifier to log into every Relying Party, collusion = between Relying Parties is possible." But this isn't the Relying Party's decision, it is? I think you mean to = say, if the client (or user) does this, it create a vulnerability where = the Relying Parties can collude=85 -- section 8: I suggest breaking each IANA requested action into its own subsection. = Otherwise the second action looks like an afterthought, or a comment on = the first. From mahoney@nostrum.com Thu Jan 5 16:43:22 2012 Return-Path: X-Original-To: gen-art@ietfa.amsl.com Delivered-To: gen-art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8885911E8080 for ; Thu, 5 Jan 2012 16:43:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NlqAkgd96OJg for ; Thu, 5 Jan 2012 16:43:22 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 0D07D11E807A for ; Thu, 5 Jan 2012 16:43:21 -0800 (PST) Received: from A-Jean-Mahoneys-MacBook-Pro.local (pool-173-57-95-103.dllstx.fios.verizon.net [173.57.95.103]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q060h9uQ090559 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Thu, 5 Jan 2012 18:43:11 -0600 (CST) (envelope-from mahoney@nostrum.com) Message-ID: <4F06439D.2020400@nostrum.com> Date: Thu, 05 Jan 2012 18:43:09 -0600 From: "A. Jean Mahoney" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: gen-art@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 173.57.95.103 is authenticated by a trusted mechanism) Subject: [Gen-art] A *new* batch of IETF LC reviews - 2012-01-05 X-BeenThere: gen-art@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "GEN-ART: General Area Review Team" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 00:43:22 -0000 Hi all, Here's the link to the new LC assignments: http://wiki.tools.ietf.org/dav/genart/reviewers-120105-lc.html The assignments are captured in the spreadsheets: http://wiki.tools.ietf.org/dav/genart/gen-art.html http://wiki.tools.ietf.org/dav/genart/gen-art-by-reviewer.html I've trimmed the spreadsheets to reflect 2012 assignments. Closed assignments can be found here: http://wiki.tools.ietf.org/dav/genart/2011%20Assignments/ And I have made the assignments in the review tool: http://art.tools.ietf.org/tools/art/genart/ The standard template is included below. Happy new year! Jean ------------------------------------------------------------------- I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at . Please resolve these comments along with any other Last Call comments you may receive. Document: Reviewer: Review Date: IETF LC End Date: IESG Telechat date: (if known) Summary: Major issues: Minor issues: Nits/editorial comments: From stephen.farrell@cs.tcd.ie Fri Jan 6 02:08:37 2012 Return-Path: X-Original-To: gen-art@ietfa.amsl.com Delivered-To: gen-art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F33821F890C for ; Fri, 6 Jan 2012 02:08:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2cK5nfSzEKfl for ; Fri, 6 Jan 2012 02:08:36 -0800 (PST) Received: from scss.tcd.ie (hermes.cs.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 886FC21F88C9 for ; Fri, 6 Jan 2012 02:08:26 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 8D92C171D32; Fri, 6 Jan 2012 10:08:25 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1325844504; bh=exDthNB1RPy1JF wsYG7gYEbFAHLnZMU9OiH66TOVk9o=; b=m1SCvYw3osDWI1K0+REGgjhWlhrht6 BPPkv0yE3DgHsTLjq9IHER2DfRGbBwKq2l8maZG7bwMLDsGTY/E8GufboaAyMOT5 APWh8y5DWyEnU3eQyHWSB1PJdDI7xsRBqPBT7t7pWJeJfeTAYk1EbE5LWdoxEAJU b4CtG/NuSPsvb766oTkGvVIvpSwv4RuzlKTzXbmCSrdFUfKQreLBccsYMxw7P94w p08GY7x+UdlEMUVe9NHclhp+NgFcU99RkV25WGKBT1FgWyS2U7cSwGEN4rUKhS0M uqPDj7zP4DKoW7WzMFj1ROO/SNTnAQAQMdZc5o5zCp4WpeVR3Pa2FkYw== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id e1I8KmVMKJP5; Fri, 6 Jan 2012 10:08:24 +0000 (GMT) Received: from [IPv6:2001:770:10:203:a288:b4ff:fe9c:bc5c] (unknown [IPv6:2001:770:10:203:a288:b4ff:fe9c:bc5c]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 0755D171CCD; Fri, 6 Jan 2012 10:08:21 +0000 (GMT) Message-ID: <4F06C816.7040603@cs.tcd.ie> Date: Fri, 06 Jan 2012 10:08:22 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Klaas Wierenga References: <3D6A7926-001A-409D-BC01-B45AD8C68AEC@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: Ben Campbell , "gen-art@ietf.org Review Team" , Sam Hartman , draft-ietf-kitten-sasl-saml.all@tools.ietf.org, "kitten-chairs@tools.ietf.org" Subject: Re: [Gen-art] Gen-ART LC Review of draft-ietf-kitten-sasl-saml-06 X-BeenThere: gen-art@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "GEN-ART: General Area Review Team" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 10:08:37 -0000 Hi Klaas, Looks like those would justify a revised ID. If you've time to do that in the next week then please go ahead and shoot out a new version. IESG folk won't have started reviewing it before then probably and this review would probably generate a discuss or comment we'd want to fix anyway. Cheers, S. PS: I cc'd Sam Hartman who's the assigned secdir reviewer. Be good if you can let him know if you plan to do a new rev before he does his review. On 01/06/2012 09:53 AM, Klaas Wierenga wrote: > Ben, > > Thanks for your thorough review! > > Klaas > > On Jan 5, 2012, at 11:32 PM, Ben Campbell wrote: > >> >> I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at. >> >> Please resolve these comments along with any other Last Call comments you may receive. >> >> Document: draft-ietf-kitten-sasl-saml-06 >> Reviewer: Ben Campbell >> Review Date: 2012-01-05 >> IETF LC End Date:2012-01-05 >> IESG Telechat date: (if known) >> >> Summary: This draft is on the right track for publication as a proposed standard. However, there are a few minor issues, and sufficient editorial issues to make the document difficult to understand. >> >> *** I noticed shortly before sending this that the authors submitted version 07 today. I have not reviewed that version--this review refers to version 06. >> >> Major issues: >> >> None >> >> Minor issues: >> >> -- section 3.2, last paragraph: "� needs to correlate the TCP session from the SASL client with the SAML authentication." >> >> Please elaborate on this correlation >> >> -- section 4, 2nd paragraph: "The SAML Idenity Provider does not have a role in GSS-API, and is considered an internal matter for the OpenID mechanism." >> >> Please elaborate, as this is the only mention of OpenID in the draft. It seems out of context. (If OpenID was in fact intended, please include a citation?) >> >> -- section 4, 3rd and 4th paragraph (paragraph a and b) >> >> These seem like protocol affecting differences. If so, they need elaboration, such as normative statements and formal definitions, or references to such. >> >> -- section 5, general: >> >> The section seems to need further elaboration or references >> >> -- section 6.1, step 5 (alt) >> >> Please describe the circumstances where the alternative step would occur. (also, please spell out "alternative") >> >> -- section 6.1, step 6: "The client now sends the URL to a browser for processing." >> >> Isn't that a question of software design rather than protocol? (unless you mean something more abstract by "browser", in which case it would help to say so.) >> >> Also, this section compresses the interaction with the identity provider. Why not show the details for those steps like the others? (If you mean them to be out of scope, then why give as much detail as you do?) >> >> -- section 6.2: >> >> The draft does not provide the decoding of the Base64 encoded parts like it did in 6.1, Without the decodes, the example is not very illuminating. >> >> -- section 7.4: "This is an option the user has to understand and decide to use if the IdP is supporting it." >> >> I doubt end users will read this spec. What does this mean for implementors? >> >> >> >> Nits/editorial comments: >> >> -- General: >> >> There are a lot of editorial and organizational issues, some of which created difficulty in understanding the authors' intent. I noted a number of these below, but I doubt I caught everything. I suggest this draft have another detailed proofreading and editing pass before it progresses. >> >> -- Pagination is strange throughout the document. (Mostly blank pages, etc.) It's worse in the PDF version, but still not right in the text version. >> >> -- section 1.1, 2nd paragraph: >> >> Repeating the SAML 2.0 citation here would be helpful. >> >> -- section 1.2, 1st paragraph >> >> The sentence structure makes it ambiguous whether the other side of the or should be just certificate validation, or TLS with cert validation. >> >> -- section 2, list starting in 2nd paragraph: >> >> Please leave a blank line between list items. Without it, you get a wall-of-text effect that's difficult to read. >> >> -- section 2, list item 3: >> >> Is "service provider" a well defined term as used here? >> >> -- section 2, paragraph after 1st numbered list: "This will be discussed below. The steps are shown from below:" >> >> Redundant sentences. Also, I assume the discussion has already been written, so "will be" is not correct. >> >> -- section 2, 2nd paragraph after 2nd numbered list: "� flow appears as follows:" >> >> Please explicitly mention the figure number. E.g. "� flow appears as shown in Figure XX." >> >> -- section 2, figure 2: >> >> The numbers in parentheses are confusing. We just saw a numbered list that sort of corresponds to this flow, but the numbers don't match up. I realize later sections refer back to these numbers, but without some mention of that, a reader is almost certainly going to try to correlate this to the previous list. >> >> -- section 3, 1st paragraph: "Recall section 5 of [RFC4422] for what needs to be described here." >> >> That reads like an author's "to do" note to himself. Has the needed description been completed, or does it still need to be described? >> >> -- section 3, 2nd paragraph: "The name of this mechanism "SAML20"." >> >> Missing word? >> >> -- "(via "gs2-header")" >> >> Missing word? >> >> -- section 3, 3rd paragraph: "The first mechanism message from the client to the server is the "initial-response" described below." >> >> Please explicitly mention section. >> >> -- section 3, 4th paragraph: "The second mechanism message is from the server to the client, the "authentication- request" described below." >> >> I can't parse this sentence--are there missing words? Also, please mention section instead of saying "below". >> >> -- section 3.1, first paragraph: >> >> Is "authorization identifier" the same as "IdP-Identifier"? >> >> -- section 3.1, ABNF >> >> Is this the authoritative definition for "initial-response"? If so, please mention that in the text. The including section does not mention "initial-response" >> >> -- section 3.1, last paragraph: >> >> Used as follows where, the rest of this paragraph? If so, then the "used as follows" clause is redundant. Also, the paragraph would be much easier to read if you broke it into a bulleted list. >> >> The 3rd sentence is awkward. I suggest something like "The � field is used as described in section 5." >> >> Is there a word missing from the forth sentence? >> >> -- section 3.2, 1st paragraph: >> >> s/ (re)directs/ redirects . Also, what gets redirected (i.e. what is the direct object of "redirects"?) >> >> -- section 3.2, 3rd paragraph (2nd note) >> >> I can't parse this. >> >> -- section 3.2, BNF >> >> Is this the formal definition of authentication-request? The next paragraph suggests it is defined in a referenced document. If so, then the repeated definition creates confusion about which document is authoritative on the matter. (if the definition is repeated here as a courtesy, please say so explicitly) >> >> -- section 3.2, 6th paragraph: "The client now sends�" >> >> s/now/then. Also, It seems like these sections jump back and forth between message definitions and a sequence of steps. I find that confusing. It would be better to keep the "sequence of steps" and the "message definitions" separate. But if you want each section to represent one or more steps in a sequence, then please add some context (e.g. "Once the widget completes the steps in section XXX, it then �" ). Keep in mind readers often jump directly to a section from the table of contents. >> >> -- section 3.3, 2nd paragraph: "and SHALL be used to set state in the server accordingly, and it shall be used by the server" >> >> Is this new normative language, or a repeat of language from the SAML spec? >> >> -- section 4, 1st paragraph: >> >> I have difficulty parsing this. >> >> -- section 4, 2nd paragraph, final sentence: >> >> sentence fragment. >> >> -- section 5, 1st sentence: 'The "gs2-cb-flag" MUST use "n" ' >> >> � MUST be set to "n"? (Or even better, 'the [actor] MUST set the [flag] to "n" ' >> >> -- section 7 " This section will address�" >> >> Addresses ( unless you haven't addressed it yet) >> >> Also, does the GSS-API description introduce security considerations? If not, please say so. >> >> -- section 7.1, "� unless a client always verify the server identity� " >> >> s/verify/verifies >> >> -- section 7.3: "SASL servers should be aware that SAML IdPs will track - to some extent - user access to their services." >> >> I'm not sure what it means for a server to be aware of this sort of thing. You are talking about people, not servers, right? What actions do you propose implementors take to mitigate this? >> >> -- section 7.4: >> >> s/you/users >> >> "By using the same identifier to log into every Relying Party, collusion between Relying Parties is possible." >> >> But this isn't the Relying Party's decision, it is? I think you mean to say, if the client (or user) does this, it create a vulnerability where the Relying Parties can collude� >> >> -- section 8: >> >> I suggest breaking each IANA requested action into its own subsection. Otherwise the second action looks like an afterthought, or a comment on the first. >> >> >> >> >> >> >> >> >> >> >> >> > From stephen.farrell@cs.tcd.ie Fri Jan 6 02:14:26 2012 Return-Path: X-Original-To: gen-art@ietfa.amsl.com Delivered-To: gen-art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93DA721F875E for ; Fri, 6 Jan 2012 02:14:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UhD5ghPWR0UN for ; Fri, 6 Jan 2012 02:14:25 -0800 (PST) Received: from scss.tcd.ie (hermes.cs.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 33B2421F8735 for ; Fri, 6 Jan 2012 02:14:25 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 98DD3171D33; Fri, 6 Jan 2012 10:14:24 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1325844864; bh=Wmnyf1M1W9+n0M npssyOfl9DAhyJbFH/YENXTUhkigk=; b=OhInFmPn2KwypzUxbcrSiAkTTb9hC9 edbCI4P75/NMb0QvvlC+6e6zg1nl/c3e9Vn4Ses+e/BZp1aFyW19zWjUExNzq2qf H0+6cPlYt8P1OBuKn5CB4vuuBNEcIqEWD8rTCdQkUR23d2fIsDxO84/ttu9SMFCq IIk7yVuMgBn6evNeDwqg5MvhIVhfiOMFSuvEbQ4/baO9FdMCS4CYDL7VEEgE2dQg 0aELeOdOhy25c6OQ8S+HC9WTUnZcI10AO9BjhtsNgWC31aJ9hsEkMY2zQrZsiTmw 42eAuCmK5qtm7qHiPxhjxv8OaDn2ErrBTtjzdyGIsIdikdQSOo0BMWDQ== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id iEEjDB8OVKso; Fri, 6 Jan 2012 10:14:24 +0000 (GMT) Received: from [IPv6:2001:770:10:203:a288:b4ff:fe9c:bc5c] (unknown [IPv6:2001:770:10:203:a288:b4ff:fe9c:bc5c]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 91D2D171CCD; Fri, 6 Jan 2012 10:14:23 +0000 (GMT) Message-ID: <4F06C97F.6030808@cs.tcd.ie> Date: Fri, 06 Jan 2012 10:14:23 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Klaas Wierenga References: <3D6A7926-001A-409D-BC01-B45AD8C68AEC@nostrum.com> <4F06C816.7040603@cs.tcd.ie> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: Ben Campbell , "gen-art@ietf.org Review Team" , Sam Hartman , draft-ietf-kitten-sasl-saml.all@tools.ietf.org, "kitten-chairs@tools.ietf.org" Subject: Re: [Gen-art] Gen-ART LC Review of draft-ietf-kitten-sasl-saml-06 X-BeenThere: gen-art@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "GEN-ART: General Area Review Team" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 10:14:26 -0000 On 01/06/2012 10:12 AM, Klaas Wierenga wrote: > Hi Stephen, > > I think I'll be able to crank out a new version before the end of next week. Great. > I don't think that should stop Sam however from doing a security review as soon when he is up for it, most comments appear to be cosmetic. Well, at least he now has the choice and won't be peeved if your new one pops out when he half-way done;-) S. > > Klaas > > > On Jan 6, 2012, at 11:08 AM, Stephen Farrell wrote: > >> >> Hi Klaas, >> >> Looks like those would justify a revised ID. If you've >> time to do that in the next week then please go ahead >> and shoot out a new version. IESG folk won't have >> started reviewing it before then probably and this >> review would probably generate a discuss or comment >> we'd want to fix anyway. >> >> Cheers, >> S. >> >> PS: I cc'd Sam Hartman who's the assigned secdir >> reviewer. Be good if you can let him know if you >> plan to do a new rev before he does his review. >> >> On 01/06/2012 09:53 AM, Klaas Wierenga wrote: >>> Ben, >>> >>> Thanks for your thorough review! >>> >>> Klaas >>> >>> On Jan 5, 2012, at 11:32 PM, Ben Campbell wrote: >>> >>>> >>>> I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at. >>>> >>>> Please resolve these comments along with any other Last Call comments you may receive. >>>> >>>> Document: draft-ietf-kitten-sasl-saml-06 >>>> Reviewer: Ben Campbell >>>> Review Date: 2012-01-05 >>>> IETF LC End Date:2012-01-05 >>>> IESG Telechat date: (if known) >>>> >>>> Summary: This draft is on the right track for publication as a proposed standard. However, there are a few minor issues, and sufficient editorial issues to make the document difficult to understand. >>>> >>>> *** I noticed shortly before sending this that the authors submitted version 07 today. I have not reviewed that version--this review refers to version 06. >>>> >>>> Major issues: >>>> >>>> None >>>> >>>> Minor issues: >>>> >>>> -- section 3.2, last paragraph: "� needs to correlate the TCP session from the SASL client with the SAML authentication." >>>> >>>> Please elaborate on this correlation >>>> >>>> -- section 4, 2nd paragraph: "The SAML Idenity Provider does not have a role in GSS-API, and is considered an internal matter for the OpenID mechanism." >>>> >>>> Please elaborate, as this is the only mention of OpenID in the draft. It seems out of context. (If OpenID was in fact intended, please include a citation?) >>>> >>>> -- section 4, 3rd and 4th paragraph (paragraph a and b) >>>> >>>> These seem like protocol affecting differences. If so, they need elaboration, such as normative statements and formal definitions, or references to such. >>>> >>>> -- section 5, general: >>>> >>>> The section seems to need further elaboration or references >>>> >>>> -- section 6.1, step 5 (alt) >>>> >>>> Please describe the circumstances where the alternative step would occur. (also, please spell out "alternative") >>>> >>>> -- section 6.1, step 6: "The client now sends the URL to a browser for processing." >>>> >>>> Isn't that a question of software design rather than protocol? (unless you mean something more abstract by "browser", in which case it would help to say so.) >>>> >>>> Also, this section compresses the interaction with the identity provider. Why not show the details for those steps like the others? (If you mean them to be out of scope, then why give as much detail as you do?) >>>> >>>> -- section 6.2: >>>> >>>> The draft does not provide the decoding of the Base64 encoded parts like it did in 6.1, Without the decodes, the example is not very illuminating. >>>> >>>> -- section 7.4: "This is an option the user has to understand and decide to use if the IdP is supporting it." >>>> >>>> I doubt end users will read this spec. What does this mean for implementors? >>>> >>>> >>>> >>>> Nits/editorial comments: >>>> >>>> -- General: >>>> >>>> There are a lot of editorial and organizational issues, some of which created difficulty in understanding the authors' intent. I noted a number of these below, but I doubt I caught everything. I suggest this draft have another detailed proofreading and editing pass before it progresses. >>>> >>>> -- Pagination is strange throughout the document. (Mostly blank pages, etc.) It's worse in the PDF version, but still not right in the text version. >>>> >>>> -- section 1.1, 2nd paragraph: >>>> >>>> Repeating the SAML 2.0 citation here would be helpful. >>>> >>>> -- section 1.2, 1st paragraph >>>> >>>> The sentence structure makes it ambiguous whether the other side of the or should be just certificate validation, or TLS with cert validation. >>>> >>>> -- section 2, list starting in 2nd paragraph: >>>> >>>> Please leave a blank line between list items. Without it, you get a wall-of-text effect that's difficult to read. >>>> >>>> -- section 2, list item 3: >>>> >>>> Is "service provider" a well defined term as used here? >>>> >>>> -- section 2, paragraph after 1st numbered list: "This will be discussed below. The steps are shown from below:" >>>> >>>> Redundant sentences. Also, I assume the discussion has already been written, so "will be" is not correct. >>>> >>>> -- section 2, 2nd paragraph after 2nd numbered list: "� flow appears as follows:" >>>> >>>> Please explicitly mention the figure number. E.g. "� flow appears as shown in Figure XX." >>>> >>>> -- section 2, figure 2: >>>> >>>> The numbers in parentheses are confusing. We just saw a numbered list that sort of corresponds to this flow, but the numbers don't match up. I realize later sections refer back to these numbers, but without some mention of that, a reader is almost certainly going to try to correlate this to the previous list. >>>> >>>> -- section 3, 1st paragraph: "Recall section 5 of [RFC4422] for what needs to be described here." >>>> >>>> That reads like an author's "to do" note to himself. Has the needed description been completed, or does it still need to be described? >>>> >>>> -- section 3, 2nd paragraph: "The name of this mechanism "SAML20"." >>>> >>>> Missing word? >>>> >>>> -- "(via "gs2-header")" >>>> >>>> Missing word? >>>> >>>> -- section 3, 3rd paragraph: "The first mechanism message from the client to the server is the "initial-response" described below." >>>> >>>> Please explicitly mention section. >>>> >>>> -- section 3, 4th paragraph: "The second mechanism message is from the server to the client, the "authentication- request" described below." >>>> >>>> I can't parse this sentence--are there missing words? Also, please mention section instead of saying "below". >>>> >>>> -- section 3.1, first paragraph: >>>> >>>> Is "authorization identifier" the same as "IdP-Identifier"? >>>> >>>> -- section 3.1, ABNF >>>> >>>> Is this the authoritative definition for "initial-response"? If so, please mention that in the text. The including section does not mention "initial-response" >>>> >>>> -- section 3.1, last paragraph: >>>> >>>> Used as follows where, the rest of this paragraph? If so, then the "used as follows" clause is redundant. Also, the paragraph would be much easier to read if you broke it into a bulleted list. >>>> >>>> The 3rd sentence is awkward. I suggest something like "The � field is used as described in section 5." >>>> >>>> Is there a word missing from the forth sentence? >>>> >>>> -- section 3.2, 1st paragraph: >>>> >>>> s/ (re)directs/ redirects . Also, what gets redirected (i.e. what is the direct object of "redirects"?) >>>> >>>> -- section 3.2, 3rd paragraph (2nd note) >>>> >>>> I can't parse this. >>>> >>>> -- section 3.2, BNF >>>> >>>> Is this the formal definition of authentication-request? The next paragraph suggests it is defined in a referenced document. If so, then the repeated definition creates confusion about which document is authoritative on the matter. (if the definition is repeated here as a courtesy, please say so explicitly) >>>> >>>> -- section 3.2, 6th paragraph: "The client now sends�" >>>> >>>> s/now/then. Also, It seems like these sections jump back and forth between message definitions and a sequence of steps. I find that confusing. It would be better to keep the "sequence of steps" and the "message definitions" separate. But if you want each section to represent one or more steps in a sequence, then please add some context (e.g. "Once the widget completes the steps in section XXX, it then �" ). Keep in mind readers often jump directly to a section from the table of contents. >>>> >>>> -- section 3.3, 2nd paragraph: "and SHALL be used to set state in the server accordingly, and it shall be used by the server" >>>> >>>> Is this new normative language, or a repeat of language from the SAML spec? >>>> >>>> -- section 4, 1st paragraph: >>>> >>>> I have difficulty parsing this. >>>> >>>> -- section 4, 2nd paragraph, final sentence: >>>> >>>> sentence fragment. >>>> >>>> -- section 5, 1st sentence: 'The "gs2-cb-flag" MUST use "n" ' >>>> >>>> � MUST be set to "n"? (Or even better, 'the [actor] MUST set the [flag] to "n" ' >>>> >>>> -- section 7 " This section will address�" >>>> >>>> Addresses ( unless you haven't addressed it yet) >>>> >>>> Also, does the GSS-API description introduce security considerations? If not, please say so. >>>> >>>> -- section 7.1, "� unless a client always verify the server identity� " >>>> >>>> s/verify/verifies >>>> >>>> -- section 7.3: "SASL servers should be aware that SAML IdPs will track - to some extent - user access to their services." >>>> >>>> I'm not sure what it means for a server to be aware of this sort of thing. You are talking about people, not servers, right? What actions do you propose implementors take to mitigate this? >>>> >>>> -- section 7.4: >>>> >>>> s/you/users >>>> >>>> "By using the same identifier to log into every Relying Party, collusion between Relying Parties is possible." >>>> >>>> But this isn't the Relying Party's decision, it is? I think you mean to say, if the client (or user) does this, it create a vulnerability where the Relying Parties can collude� >>>> >>>> -- section 8: >>>> >>>> I suggest breaking each IANA requested action into its own subsection. Otherwise the second action looks like an afterthought, or a comment on the first. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> > From klaas@cisco.com Fri Jan 6 01:53:20 2012 Return-Path: X-Original-To: gen-art@ietfa.amsl.com Delivered-To: gen-art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CC3621F88C8 for ; Fri, 6 Jan 2012 01:53:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.9 X-Spam-Level: X-Spam-Status: No, score=-5.9 tagged_above=-999 required=5 tests=[AWL=0.699, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s0k7dCcanRem for ; Fri, 6 Jan 2012 01:53:19 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 65DB921F8640 for ; Fri, 6 Jan 2012 01:53:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=klaas@cisco.com; l=9505; q=dns/txt; s=iport; t=1325843599; x=1327053199; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=Oxip/oiKs1eJtUB7MDGerDEZMSkrLhiaIZMx/xIdZLQ=; b=lOQ98AQwYOGzh6ETem4QxHviK8bl3l2jXJDVBgga9jOdwYjY2WZftAPd 1s6OUgjbe8k/szC0KU9yE6BHiN06HLi2icpiA1utqbQ8z0RYVTpnz7OvR frqoGyYPThjb4o/S8Jj9V059FmSxYrTLToGnt9s9C7ukPI3V6wXQG8bjF A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAMLDBk+tJXG9/2dsb2JhbAA6CaxOgQWBcgEBAQMBEgFmEAsUMlcGNYdYCJd+AZ4hiFeCV2MElQeSNg X-IronPort-AV: E=Sophos;i="4.71,467,1320624000"; d="scan'208";a="49148110" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-5.cisco.com with ESMTP; 06 Jan 2012 09:53:18 +0000 Received: from rtp-kwiereng-8711.cisco.com (rtp-kwiereng-8711.cisco.com [10.116.7.34]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id q069rH6Z029293; Fri, 6 Jan 2012 09:53:18 GMT Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=windows-1252 From: Klaas Wierenga In-Reply-To: <3D6A7926-001A-409D-BC01-B45AD8C68AEC@nostrum.com> Date: Fri, 6 Jan 2012 10:53:16 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3D6A7926-001A-409D-BC01-B45AD8C68AEC@nostrum.com> To: Ben Campbell X-Mailer: Apple Mail (2.1251.1) X-Mailman-Approved-At: Fri, 06 Jan 2012 05:26:43 -0800 Cc: "gen-art@ietf.org Review Team" , draft-ietf-kitten-sasl-saml.all@tools.ietf.org Subject: Re: [Gen-art] Gen-ART LC Review of draft-ietf-kitten-sasl-saml-06 X-BeenThere: gen-art@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "GEN-ART: General Area Review Team" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 09:53:20 -0000 Ben, Thanks for your thorough review! Klaas On Jan 5, 2012, at 11:32 PM, Ben Campbell wrote: >=20 > I am the assigned Gen-ART reviewer for this draft. For background on = Gen-ART, please see the FAQ at = . >=20 > Please resolve these comments along with any other Last Call comments = you may receive. >=20 > Document: draft-ietf-kitten-sasl-saml-06 > Reviewer: Ben Campbell > Review Date: 2012-01-05 > IETF LC End Date:2012-01-05 > IESG Telechat date: (if known) >=20 > Summary: This draft is on the right track for publication as a = proposed standard. However, there are a few minor issues, and sufficient = editorial issues to make the document difficult to understand.=20 >=20 > *** I noticed shortly before sending this that the authors submitted = version 07 today. I have not reviewed that version--this review refers = to version 06. >=20 > Major issues: >=20 > None >=20 > Minor issues: >=20 > -- section 3.2, last paragraph: "=85 needs to correlate the TCP = session from the SASL client with the SAML authentication." >=20 > Please elaborate on this correlation >=20 > -- section 4, 2nd paragraph: "The SAML Idenity Provider does not have = a role in GSS-API, and is considered an internal matter for the OpenID = mechanism." >=20 > Please elaborate, as this is the only mention of OpenID in the draft. = It seems out of context. (If OpenID was in fact intended, please = include a citation?) >=20 > -- section 4, 3rd and 4th paragraph (paragraph a and b) >=20 > These seem like protocol affecting differences. If so, they need = elaboration, such as normative statements and formal definitions, or = references to such. >=20 > -- section 5, general: >=20 > The section seems to need further elaboration or references >=20 > -- section 6.1, step 5 (alt) >=20 > Please describe the circumstances where the alternative step would = occur. (also, please spell out "alternative")=20 >=20 > -- section 6.1, step 6: "The client now sends the URL to a browser for = processing." >=20 > Isn't that a question of software design rather than protocol? (unless = you mean something more abstract by "browser", in which case it would = help to say so.) >=20 > Also, this section compresses the interaction with the identity = provider. Why not show the details for those steps like the others? (If = you mean them to be out of scope, then why give as much detail as you = do?) >=20 > -- section 6.2: >=20 > The draft does not provide the decoding of the Base64 encoded parts = like it did in 6.1, Without the decodes, the example is not very = illuminating. >=20 > -- section 7.4: "This is an option the user has to understand and = decide to use if the IdP is supporting it." >=20 > I doubt end users will read this spec. What does this mean for = implementors? >=20 >=20 >=20 > Nits/editorial comments: >=20 > -- General: >=20 > There are a lot of editorial and organizational issues, some of which = created difficulty in understanding the authors' intent. I noted a = number of these below, but I doubt I caught everything. I suggest this = draft have another detailed proofreading and editing pass before it = progresses. >=20 > -- Pagination is strange throughout the document. (Mostly blank pages, = etc.) It's worse in the PDF version, but still not right in the text = version. >=20 > -- section 1.1, 2nd paragraph: >=20 > Repeating the SAML 2.0 citation here would be helpful. >=20 > -- section 1.2, 1st paragraph >=20 > The sentence structure makes it ambiguous whether the other side of = the or should be just certificate validation, or TLS with cert = validation.=20 >=20 > -- section 2, list starting in 2nd paragraph: >=20 > Please leave a blank line between list items. Without it, you get a = wall-of-text effect that's difficult to read. >=20 > -- section 2, list item 3: >=20 > Is "service provider" a well defined term as used here? >=20 > -- section 2, paragraph after 1st numbered list: "This will be = discussed below. The steps are shown from below:" >=20 > Redundant sentences. Also, I assume the discussion has already been = written, so "will be" is not correct. >=20 > -- section 2, 2nd paragraph after 2nd numbered list: "=85 flow appears = as follows:" >=20 > Please explicitly mention the figure number. E.g. "=85 flow appears as = shown in Figure XX." >=20 > -- section 2, figure 2: >=20 > The numbers in parentheses are confusing. We just saw a numbered list = that sort of corresponds to this flow, but the numbers don't match up. I = realize later sections refer back to these numbers, but without some = mention of that, a reader is almost certainly going to try to correlate = this to the previous list. >=20 > -- section 3, 1st paragraph: "Recall section 5 of [RFC4422] for what = needs to be described here." >=20 > That reads like an author's "to do" note to himself. Has the needed = description been completed, or does it still need to be described? >=20 > -- section 3, 2nd paragraph: "The name of this mechanism "SAML20"." >=20 > Missing word? >=20 > -- "(via "gs2-header")" >=20 > Missing word? >=20 > -- section 3, 3rd paragraph: "The first mechanism message from the = client to the server is the "initial-response" described below." >=20 > Please explicitly mention section.=20 >=20 > -- section 3, 4th paragraph: "The second mechanism message is from the = server to the client, the "authentication- request" described below." >=20 > I can't parse this sentence--are there missing words? Also, please = mention section instead of saying "below". >=20 > -- section 3.1, first paragraph: >=20 > Is "authorization identifier" the same as "IdP-Identifier"? >=20 > -- section 3.1, ABNF >=20 > Is this the authoritative definition for "initial-response"? If so, = please mention that in the text. The including section does not mention = "initial-response" >=20 > -- section 3.1, last paragraph: >=20 > Used as follows where, the rest of this paragraph? If so, then the = "used as follows" clause is redundant. Also, the paragraph would be much = easier to read if you broke it into a bulleted list. >=20 > The 3rd sentence is awkward. I suggest something like "The =85 field = is used as described in section 5." >=20 > Is there a word missing from the forth sentence?=20 >=20 > -- section 3.2, 1st paragraph: >=20 > s/ (re)directs/ redirects . Also, what gets redirected (i.e. what is = the direct object of "redirects"?) >=20 > -- section 3.2, 3rd paragraph (2nd note) >=20 > I can't parse this. >=20 > -- section 3.2, BNF >=20 > Is this the formal definition of authentication-request? The next = paragraph suggests it is defined in a referenced document. If so, then = the repeated definition creates confusion about which document is = authoritative on the matter. (if the definition is repeated here as a = courtesy, please say so explicitly) >=20 > -- section 3.2, 6th paragraph: "The client now sends=85" >=20 > s/now/then. Also, It seems like these sections jump back and forth = between message definitions and a sequence of steps. I find that = confusing. It would be better to keep the "sequence of steps" and the = "message definitions" separate. But if you want each section to = represent one or more steps in a sequence, then please add some context = (e.g. "Once the widget completes the steps in section XXX, it then =85" = ). Keep in mind readers often jump directly to a section from the table = of contents. >=20 > -- section 3.3, 2nd paragraph: "and SHALL be used to set state in the = server accordingly, and it shall be used by the server" >=20 > Is this new normative language, or a repeat of language from the SAML = spec? >=20 > -- section 4, 1st paragraph: >=20 > I have difficulty parsing this. >=20 > -- section 4, 2nd paragraph, final sentence: >=20 > sentence fragment. >=20 > -- section 5, 1st sentence: 'The "gs2-cb-flag" MUST use "n" ' >=20 > =85 MUST be set to "n"? (Or even better, 'the [actor] MUST set the = [flag] to "n" ' >=20 > -- section 7 " This section will address=85" >=20 > Addresses ( unless you haven't addressed it yet) >=20 > Also, does the GSS-API description introduce security considerations? = If not, please say so. >=20 > -- section 7.1, "=85 unless a client always verify the server = identity=85 " >=20 > s/verify/verifies >=20 > -- section 7.3: "SASL servers should be aware that SAML IdPs will = track - to some extent - user access to their services." >=20 > I'm not sure what it means for a server to be aware of this sort of = thing. You are talking about people, not servers, right? What actions do = you propose implementors take to mitigate this? >=20 > -- section 7.4: >=20 > s/you/users >=20 > "By using the same identifier to log into every Relying Party, = collusion between Relying Parties is possible." >=20 > But this isn't the Relying Party's decision, it is? I think you mean = to say, if the client (or user) does this, it create a vulnerability = where the Relying Parties can collude=85 >=20 > -- section 8: >=20 > I suggest breaking each IANA requested action into its own subsection. = Otherwise the second action looks like an afterthought, or a comment on = the first. >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 From klaas@cisco.com Fri Jan 6 02:12:39 2012 Return-Path: X-Original-To: gen-art@ietfa.amsl.com Delivered-To: gen-art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 808F221F88B6 for ; Fri, 6 Jan 2012 02:12:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6 X-Spam-Level: X-Spam-Status: No, score=-6 tagged_above=-999 required=5 tests=[AWL=0.599, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BdNtcvrN4WZM for ; Fri, 6 Jan 2012 02:12:37 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 3955421F88C9 for ; Fri, 6 Jan 2012 02:12:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=klaas@cisco.com; l=10805; q=dns/txt; s=iport; t=1325844757; x=1327054357; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=Ey6ZQxfBoqZUAPaTVujddd0geyYRGqVAyHf+wKgwWzM=; b=M1T/WvwperijyxqNAgumUOc6y6JUvAHQ48s/uzMcIEmp7REAU8TQxW83 4axjLdDHgDjgsTfj03rcWCB+dErRBvArts1EpGVwtjML3RpcgzCrDj5cO k/MetUsidPufirpFE4SgxDFtFrQbfw+UK4/Lm6YuIoCKad6nSE0esY8Ku c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAP3HBk+tJV2Z/2dsb2JhbAA6CaxIgQWBcgEBAQMBEgFmEAsUBC5XBjWHWAiYBAGeI4hXgldjBJUHkjY X-IronPort-AV: E=Sophos;i="4.71,467,1320624000"; d="scan'208";a="49127629" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-6.cisco.com with ESMTP; 06 Jan 2012 10:12:36 +0000 Received: from rtp-kwiereng-8711.cisco.com (rtp-kwiereng-8711.cisco.com [10.116.7.34]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q06ACYcv019787; Fri, 6 Jan 2012 10:12:35 GMT Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=windows-1252 From: Klaas Wierenga In-Reply-To: <4F06C816.7040603@cs.tcd.ie> Date: Fri, 6 Jan 2012 11:12:34 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3D6A7926-001A-409D-BC01-B45AD8C68AEC@nostrum.com> <4F06C816.7040603@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1251.1) X-Mailman-Approved-At: Fri, 06 Jan 2012 05:26:43 -0800 Cc: Ben Campbell , "gen-art@ietf.org Review Team" , Sam Hartman , draft-ietf-kitten-sasl-saml.all@tools.ietf.org, "kitten-chairs@tools.ietf.org" Subject: Re: [Gen-art] Gen-ART LC Review of draft-ietf-kitten-sasl-saml-06 X-BeenThere: gen-art@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "GEN-ART: General Area Review Team" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 10:12:39 -0000 Hi Stephen, I think I'll be able to crank out a new version before the end of next = week. I don't think that should stop Sam however from doing a security = review as soon when he is up for it, most comments appear to be = cosmetic. Klaas On Jan 6, 2012, at 11:08 AM, Stephen Farrell wrote: >=20 > Hi Klaas, >=20 > Looks like those would justify a revised ID. If you've > time to do that in the next week then please go ahead > and shoot out a new version. IESG folk won't have > started reviewing it before then probably and this > review would probably generate a discuss or comment > we'd want to fix anyway. >=20 > Cheers, > S. >=20 > PS: I cc'd Sam Hartman who's the assigned secdir > reviewer. Be good if you can let him know if you > plan to do a new rev before he does his review. >=20 > On 01/06/2012 09:53 AM, Klaas Wierenga wrote: >> Ben, >>=20 >> Thanks for your thorough review! >>=20 >> Klaas >>=20 >> On Jan 5, 2012, at 11:32 PM, Ben Campbell wrote: >>=20 >>>=20 >>> I am the assigned Gen-ART reviewer for this draft. For background on = Gen-ART, please see the FAQ = at. >>>=20 >>> Please resolve these comments along with any other Last Call = comments you may receive. >>>=20 >>> Document: draft-ietf-kitten-sasl-saml-06 >>> Reviewer: Ben Campbell >>> Review Date: 2012-01-05 >>> IETF LC End Date:2012-01-05 >>> IESG Telechat date: (if known) >>>=20 >>> Summary: This draft is on the right track for publication as a = proposed standard. However, there are a few minor issues, and sufficient = editorial issues to make the document difficult to understand. >>>=20 >>> *** I noticed shortly before sending this that the authors submitted = version 07 today. I have not reviewed that version--this review refers = to version 06. >>>=20 >>> Major issues: >>>=20 >>> None >>>=20 >>> Minor issues: >>>=20 >>> -- section 3.2, last paragraph: "=85 needs to correlate the TCP = session from the SASL client with the SAML authentication." >>>=20 >>> Please elaborate on this correlation >>>=20 >>> -- section 4, 2nd paragraph: "The SAML Idenity Provider does not = have a role in GSS-API, and is considered an internal matter for the = OpenID mechanism." >>>=20 >>> Please elaborate, as this is the only mention of OpenID in the = draft. It seems out of context. (If OpenID was in fact intended, please = include a citation?) >>>=20 >>> -- section 4, 3rd and 4th paragraph (paragraph a and b) >>>=20 >>> These seem like protocol affecting differences. If so, they need = elaboration, such as normative statements and formal definitions, or = references to such. >>>=20 >>> -- section 5, general: >>>=20 >>> The section seems to need further elaboration or references >>>=20 >>> -- section 6.1, step 5 (alt) >>>=20 >>> Please describe the circumstances where the alternative step would = occur. (also, please spell out "alternative") >>>=20 >>> -- section 6.1, step 6: "The client now sends the URL to a browser = for processing." >>>=20 >>> Isn't that a question of software design rather than protocol? = (unless you mean something more abstract by "browser", in which case it = would help to say so.) >>>=20 >>> Also, this section compresses the interaction with the identity = provider. Why not show the details for those steps like the others? (If = you mean them to be out of scope, then why give as much detail as you = do?) >>>=20 >>> -- section 6.2: >>>=20 >>> The draft does not provide the decoding of the Base64 encoded parts = like it did in 6.1, Without the decodes, the example is not very = illuminating. >>>=20 >>> -- section 7.4: "This is an option the user has to understand and = decide to use if the IdP is supporting it." >>>=20 >>> I doubt end users will read this spec. What does this mean for = implementors? >>>=20 >>>=20 >>>=20 >>> Nits/editorial comments: >>>=20 >>> -- General: >>>=20 >>> There are a lot of editorial and organizational issues, some of = which created difficulty in understanding the authors' intent. I noted a = number of these below, but I doubt I caught everything. I suggest this = draft have another detailed proofreading and editing pass before it = progresses. >>>=20 >>> -- Pagination is strange throughout the document. (Mostly blank = pages, etc.) It's worse in the PDF version, but still not right in the = text version. >>>=20 >>> -- section 1.1, 2nd paragraph: >>>=20 >>> Repeating the SAML 2.0 citation here would be helpful. >>>=20 >>> -- section 1.2, 1st paragraph >>>=20 >>> The sentence structure makes it ambiguous whether the other side of = the or should be just certificate validation, or TLS with cert = validation. >>>=20 >>> -- section 2, list starting in 2nd paragraph: >>>=20 >>> Please leave a blank line between list items. Without it, you get a = wall-of-text effect that's difficult to read. >>>=20 >>> -- section 2, list item 3: >>>=20 >>> Is "service provider" a well defined term as used here? >>>=20 >>> -- section 2, paragraph after 1st numbered list: "This will be = discussed below. The steps are shown from below:" >>>=20 >>> Redundant sentences. Also, I assume the discussion has already been = written, so "will be" is not correct. >>>=20 >>> -- section 2, 2nd paragraph after 2nd numbered list: "=85 flow = appears as follows:" >>>=20 >>> Please explicitly mention the figure number. E.g. "=85 flow appears = as shown in Figure XX." >>>=20 >>> -- section 2, figure 2: >>>=20 >>> The numbers in parentheses are confusing. We just saw a numbered = list that sort of corresponds to this flow, but the numbers don't match = up. I realize later sections refer back to these numbers, but without = some mention of that, a reader is almost certainly going to try to = correlate this to the previous list. >>>=20 >>> -- section 3, 1st paragraph: "Recall section 5 of [RFC4422] for what = needs to be described here." >>>=20 >>> That reads like an author's "to do" note to himself. Has the needed = description been completed, or does it still need to be described? >>>=20 >>> -- section 3, 2nd paragraph: "The name of this mechanism "SAML20"." >>>=20 >>> Missing word? >>>=20 >>> -- "(via "gs2-header")" >>>=20 >>> Missing word? >>>=20 >>> -- section 3, 3rd paragraph: "The first mechanism message from the = client to the server is the "initial-response" described below." >>>=20 >>> Please explicitly mention section. >>>=20 >>> -- section 3, 4th paragraph: "The second mechanism message is from = the server to the client, the "authentication- request" described = below." >>>=20 >>> I can't parse this sentence--are there missing words? Also, please = mention section instead of saying "below". >>>=20 >>> -- section 3.1, first paragraph: >>>=20 >>> Is "authorization identifier" the same as "IdP-Identifier"? >>>=20 >>> -- section 3.1, ABNF >>>=20 >>> Is this the authoritative definition for "initial-response"? If so, = please mention that in the text. The including section does not mention = "initial-response" >>>=20 >>> -- section 3.1, last paragraph: >>>=20 >>> Used as follows where, the rest of this paragraph? If so, then the = "used as follows" clause is redundant. Also, the paragraph would be much = easier to read if you broke it into a bulleted list. >>>=20 >>> The 3rd sentence is awkward. I suggest something like "The =85 field = is used as described in section 5." >>>=20 >>> Is there a word missing from the forth sentence? >>>=20 >>> -- section 3.2, 1st paragraph: >>>=20 >>> s/ (re)directs/ redirects . Also, what gets redirected (i.e. what is = the direct object of "redirects"?) >>>=20 >>> -- section 3.2, 3rd paragraph (2nd note) >>>=20 >>> I can't parse this. >>>=20 >>> -- section 3.2, BNF >>>=20 >>> Is this the formal definition of authentication-request? The next = paragraph suggests it is defined in a referenced document. If so, then = the repeated definition creates confusion about which document is = authoritative on the matter. (if the definition is repeated here as a = courtesy, please say so explicitly) >>>=20 >>> -- section 3.2, 6th paragraph: "The client now sends=85" >>>=20 >>> s/now/then. Also, It seems like these sections jump back and forth = between message definitions and a sequence of steps. I find that = confusing. It would be better to keep the "sequence of steps" and the = "message definitions" separate. But if you want each section to = represent one or more steps in a sequence, then please add some context = (e.g. "Once the widget completes the steps in section XXX, it then =85" = ). Keep in mind readers often jump directly to a section from the table = of contents. >>>=20 >>> -- section 3.3, 2nd paragraph: "and SHALL be used to set state in = the server accordingly, and it shall be used by the server" >>>=20 >>> Is this new normative language, or a repeat of language from the = SAML spec? >>>=20 >>> -- section 4, 1st paragraph: >>>=20 >>> I have difficulty parsing this. >>>=20 >>> -- section 4, 2nd paragraph, final sentence: >>>=20 >>> sentence fragment. >>>=20 >>> -- section 5, 1st sentence: 'The "gs2-cb-flag" MUST use "n" ' >>>=20 >>> =85 MUST be set to "n"? (Or even better, 'the [actor] MUST set the = [flag] to "n" ' >>>=20 >>> -- section 7 " This section will address=85" >>>=20 >>> Addresses ( unless you haven't addressed it yet) >>>=20 >>> Also, does the GSS-API description introduce security = considerations? If not, please say so. >>>=20 >>> -- section 7.1, "=85 unless a client always verify the server = identity=85 " >>>=20 >>> s/verify/verifies >>>=20 >>> -- section 7.3: "SASL servers should be aware that SAML IdPs will = track - to some extent - user access to their services." >>>=20 >>> I'm not sure what it means for a server to be aware of this sort of = thing. You are talking about people, not servers, right? What actions do = you propose implementors take to mitigate this? >>>=20 >>> -- section 7.4: >>>=20 >>> s/you/users >>>=20 >>> "By using the same identifier to log into every Relying Party, = collusion between Relying Parties is possible." >>>=20 >>> But this isn't the Relying Party's decision, it is? I think you mean = to say, if the client (or user) does this, it create a vulnerability = where the Relying Parties can collude=85 >>>=20 >>> -- section 8: >>>=20 >>> I suggest breaking each IANA requested action into its own = subsection. Otherwise the second action looks like an afterthought, or a = comment on the first. >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>=20 From mahoney@nostrum.com Fri Jan 6 14:02:13 2012 Return-Path: X-Original-To: gen-art@ietfa.amsl.com Delivered-To: gen-art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D27D421F8716 for ; Fri, 6 Jan 2012 14:02:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EQiqUKEewxgR for ; Fri, 6 Jan 2012 14:02:13 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 3756921F8575 for ; Fri, 6 Jan 2012 14:02:12 -0800 (PST) Received: from A-Jean-Mahoneys-MacBook-Pro.local (pool-173-57-95-103.dllstx.fios.verizon.net [173.57.95.103]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q06M2ChT080711 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Fri, 6 Jan 2012 16:02:12 -0600 (CST) (envelope-from mahoney@nostrum.com) Message-ID: <4F076F64.7030700@nostrum.com> Date: Fri, 06 Jan 2012 16:02:12 -0600 From: "A. Jean Mahoney" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: gen-art@ietf.org References: <4F06439D.2020400@nostrum.com> In-Reply-To: <4F06439D.2020400@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 173.57.95.103 is authenticated by a trusted mechanism) Subject: Re: [Gen-art] A *new* batch of IETF LC reviews - 2012-01-05 X-BeenThere: gen-art@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "GEN-ART: General Area Review Team" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 22:02:14 -0000 Hi all, There has been a bit of shuffling of assignments - Alexey is taking over David's, and David is taking over Allyn's. Everything below has been updated. Thanks, Jean On 1/5/12 6:43 PM, A. Jean Mahoney wrote: > Hi all, > > Here's the link to the new LC assignments: > http://wiki.tools.ietf.org/dav/genart/reviewers-120105-lc.html > > The assignments are captured in the spreadsheets: > http://wiki.tools.ietf.org/dav/genart/gen-art.html > http://wiki.tools.ietf.org/dav/genart/gen-art-by-reviewer.html > > I've trimmed the spreadsheets to reflect 2012 assignments. Closed > assignments can be found here: > http://wiki.tools.ietf.org/dav/genart/2011%20Assignments/ > > And I have made the assignments in the review tool: > http://art.tools.ietf.org/tools/art/genart/ > > The standard template is included below. > > Happy new year! > > Jean > > ------------------------------------------------------------------- > > I am the assigned Gen-ART reviewer for this draft. For background on > Gen-ART, please see the FAQ at > . > > Please resolve these comments along with any other Last Call comments > you may receive. > > Document: > Reviewer: > Review Date: > IETF LC End Date: > IESG Telechat date: (if known) > > Summary: > > Major issues: > > Minor issues: > > Nits/editorial comments: > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art From adrian@olddog.co.uk Sat Jan 7 12:59:05 2012 Return-Path: X-Original-To: gen-art@ietfa.amsl.com Delivered-To: gen-art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C14DE21F84FF; Sat, 7 Jan 2012 12:59:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tp0E35dzxCou; Sat, 7 Jan 2012 12:59:05 -0800 (PST) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by ietfa.amsl.com (Postfix) with ESMTP id DA75A21F84DA; Sat, 7 Jan 2012 12:59:04 -0800 (PST) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id q07Kx0oB003947; Sat, 7 Jan 2012 20:59:00 GMT Received: from 950129200 (adsl-89-217-79-52.adslplus.ch [89.217.79.52]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id q07Kwsj8003918 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 7 Jan 2012 20:58:57 GMT From: "Adrian Farrel" To: "'Stig Venaas'" , Date: Sat, 7 Jan 2012 20:58:55 -0000 Message-ID: <00fa01cccd7f$2e9af670$8bd0e350$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AczNfwoNDfPXUFLMQLutSIE3Hj4WPg== Content-Language: en-gb Cc: iesg@ietf.org, 'General Area Review Team' , draft-ietf-pim-port.all@tools.ietf.org Subject: [Gen-art] Hello Russ ? [RE: Russ Housley's Discuss on draft-ietf-pim-port [Was: Gen-ART Telechat review of draft-ietf-pim-port-09.txt]] X-BeenThere: gen-art@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: "GEN-ART: General Area Review Team" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jan 2012 20:59:05 -0000 Russ, Pingy pingy ping. I've added to the informal agenda for 1/12/12 A > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > Sent: 03 January 2012 22:08 > To: 'Stig Venaas'; 'Russ Housley' > Cc: 'Suresh Krishnan'; 'draft-ietf-pim-port.all@tools.ietf.org'; 'General Area > Review Team' > Subject: RE: Russ Housley's Discuss on draft-ietf-pim-port [Was: Gen-ART > Telechat review of draft-ietf-pim-port-09.txt] > > In the hope that the change (acceptable to Suresh) will work for Russ, I have > entered the RFC Editor note. > > A > > > -----Original Message----- > > From: Stig Venaas [mailto:svenaas@cisco.com] > > Sent: 03 January 2012 17:27 > > To: Russ Housley > > Cc: Suresh Krishnan; adrian@olddog.co.uk; draft-ietf-pim- > port.all@tools.ietf.org; > > General Area Review Team > > Subject: Re: Russ's Discs on draft-ietf-pim-port [Was: Gen-ART Telechat review > of > > draft-ietf-pim-port-09.txt] > > > > Russ, I've sent 3-4 emails in December asking if your discuss can be > > resolved, but no response. I hope you can respond now. > > > > Stig > > > > On 11/28/2011 11:07 AM, Stig Venaas (svenaas) wrote: > > > On 11/29/2011 10:18 AM, Suresh Krishnan wrote: > > > > Hi Stig, > > > > > > > > > > > > On 11/28/2011 12:59 PM, Stig Venaas wrote: > > > >>> Please note that the Connection ID AFI in the PORT Hello Option > > > does not > > > >>> need to match the address family of PIM Hello message that carries it. > > > >>> e.g. an IPv6 PIM Hello message could contain a PORT Hello Option with a > > > >>> TCP Connection ID AFI of 1 (IPv4). > > > >> > > > >> While I am OK with this text, wouldn't it be better to add this to 3.1 > > > >> and 3.2 where we formally define the hello options? > > > >> > > > >> My proposal would be: > > > >> > > > >> End of 3.1: > > > >> > > > >> OLD: > > > >> TCP Connection ID AFI: The AFI value to describe the address-family > > > >> of the address of the TCP Connection ID field. When this field is > > > >> 0, a mechanism outside the scope of this document is used to > > > >> obtain the addresses used to establish the TCP connection. > > > >> > > > >> NEW: > > > >> TCP Connection ID AFI: The AFI value to describe the address-family > > > >> of the address of the TCP Connection ID field. Note that this > > > >> value does not need to match the address-family of the PIM Hello > > > >> message that carries it. When this field is 0, a mechanism > > > >> outside the scope of this document is used to obtain the > > > >> addresses used to establish the TCP connection. > > > >> > > > >> End of 3.2: > > > >> > > > >> OLD: > > > >> SCTP Connection ID AFI: The AFI value to describe the address- > > > >> family of the address of the SCTP Connection ID field. When this > > > >> field is 0, a mechanism outside the scope of this document is used > > > >> to obtain the addresses used to establish the SCTP connection. > > > >> > > > >> NEW: > > > >> SCTP Connection ID AFI: The AFI value to describe the address- > > > >> family of the address of the SCTP Connection ID field. Note that > > > >> this value does not need to match the address-family of the PIM > > > >> Hello message that carries it. When this field is 0, a mechanism > > > >> outside the scope of this document is used to obtain the > > > >> addresses used to establish the SCTP connection. > > > >> > > > >> What do you think? > > > > > > > > This works great. > > > > > > Great, I hope we can then just add a note for the editor, and that the > > > discuss can be cleared... > > > > > > Stig > > > > > > > > > > > Thanks > > > > Suresh > > > From brian.e.carpenter@gmail.com Sat Jan 7 15:12:05 2012 Return-Path: X-Original-To: gen-art@ietfa.amsl.com Delivered-To: gen-art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0818321F84AF for ; Sat, 7 Jan 2012 15:12:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.563 X-Spam-Level: X-Spam-Status: No, score=-103.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tyhx+2RER3mG for ; Sat, 7 Jan 2012 15:12:00 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 23DE921F84AE for ; Sat, 7 Jan 2012 15:11:59 -0800 (PST) Received: by eekc14 with SMTP id c14so1720201eek.31 for ; Sat, 07 Jan 2012 15:11:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to :subject:content-type; bh=9xiu/6hlCNj4AbrQBFNMDzRE8IVAmpuCGik4YLNXpRU=; b=bktAymE3+ounMYAWGK5F3cRcjMkxDT3t/chP/P975ANj+AUQ70dnkfvUx5FKw2L41f kAUubrwF4HyKKyeDNOyKU1HwJqcArSSg/wvx1ewQbl0FndVvW8PSd84YxwYk5Ru5oRUq 1rWh3EqgXFiIndYsO3fxG7/2kIiqeOIx/WNZ8= Received: by 10.14.2.15 with SMTP id 15mr4193707eee.29.1325977919371; Sat, 07 Jan 2012 15:11:59 -0800 (PST) Received: from [10.1.1.4] ([121.98.251.219]) by mx.google.com with ESMTPS id u53sm220621073eeu.6.2012.01.07.15.11.56 (version=SSLv3 cipher=OTHER); Sat, 07 Jan 2012 15:11:59 -0800 (PST) Message-ID: <4F08D135.9080303@gmail.com> Date: Sun, 08 Jan 2012 12:11:49 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: draft-gerhards-syslog-plain-tcp.all@tools.ietf.org, General Area Review Team Content-Type: multipart/mixed; boundary="------------060203080003030101000102" Subject: [Gen-art] Gen-ART LC review of draft-gerhards-syslog-plain-tcp-13.txt X-BeenThere: gen-art@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "GEN-ART: General Area Review Team" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jan 2012 23:12:05 -0000 This is a multi-part message in MIME format. --------------060203080003030101000102 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Please see attached review. --------------060203080003030101000102 Content-Type: text/plain; name="draft-gerhards-syslog-plain-tcp-13-carpenter.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="draft-gerhards-syslog-plain-tcp-13-carpenter.txt" SSBhbSB0aGUgYXNzaWduZWQgR2VuLUFSVCByZXZpZXdlciBmb3IgdGhpcyBkcmFmdC4gRm9y IGJhY2tncm91bmQgb24NCkdlbi1BUlQsIHBsZWFzZSBzZWUgdGhlIEZBUSBhdA0KPGh0dHA6 Ly93aWtpLnRvb2xzLmlldGYub3JnL2FyZWEvZ2VuL3RyYWMvd2lraS9HZW5BcnRmYXE+Lg0K DQpQbGVhc2UgcmVzb2x2ZSB0aGVzZSBjb21tZW50cyBhbG9uZyB3aXRoIGFueSBvdGhlciBM YXN0IENhbGwgY29tbWVudHMNCnlvdSBtYXkgcmVjZWl2ZS4NCg0KRG9jdW1lbnQ6IGRyYWZ0 LWdlcmhhcmRzLXN5c2xvZy1wbGFpbi10Y3AtMTMudHh0DQpSZXZpZXdlcjogQnJpYW4gQ2Fy cGVudGVyDQpSZXZpZXcgRGF0ZTogMjAxMi0wMS0wOA0KSUVURiBMQyBFbmQgRGF0ZTogMjAx Mi0wMS0zMA0KSUVTRyBUZWxlY2hhdCBkYXRlOiANCg0KU3VtbWFyeTogIFJlYWR5DQotLS0t LS0tLQ0KDQpDb21tZW50czoNCi0tLS0tLS0tLQ0KDQpBbGwgdGhlIGNoYW5nZXMgZnJvbSB0 aGUgcHJldmlvdXMgdmVyc2lvbiBhcmUgaW1wcm92ZW1lbnRzLg0K --------------060203080003030101000102-- From david.black@emc.com Tue Jan 10 18:44:43 2012 Return-Path: X-Original-To: gen-art@ietfa.amsl.com Delivered-To: gen-art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 231A321F847C; Tue, 10 Jan 2012 18:44:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.592 X-Spam-Level: X-Spam-Status: No, score=-106.592 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KfruPwjNhBJW; Tue, 10 Jan 2012 18:44:42 -0800 (PST) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id 5AC3E21F8499; Tue, 10 Jan 2012 18:44:42 -0800 (PST) Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q0B2iWxI019520 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Jan 2012 21:44:32 -0500 Received: from mailhub.lss.emc.com (mailhubhoprd02.lss.emc.com [10.254.221.253]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor); Tue, 10 Jan 2012 21:44:19 -0500 Received: from mxhub08.corp.emc.com (mxhub08.corp.emc.com [128.222.70.205]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q0B2iIN1003220; Tue, 10 Jan 2012 21:44:18 -0500 Received: from mx14a.corp.emc.com ([169.254.1.99]) by mxhub08.corp.emc.com ([128.222.70.205]) with mapi; Tue, 10 Jan 2012 21:44:18 -0500 From: To: , , , Date: Tue, 10 Jan 2012 21:44:16 -0500 Thread-Topic: Gen-ART review of draft-ietf-marf-redaction-04 Thread-Index: AczQCujbMXhqirD5Sk6EB1sS2KVtOQ== Message-ID: <7C4DFCE962635144B8FAE8CA11D0BF1E05A7B80D63@MX14A.corp.emc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Cc: presnick@qualcomm.com, marf@ietf.org Subject: [Gen-art] Gen-ART review of draft-ietf-marf-redaction-04 X-BeenThere: gen-art@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "GEN-ART: General Area Review Team" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 02:44:43 -0000 I am the assigned Gen-ART reviewer for this draft. For background on Gen-AR= T, please see the FAQ at . Please resolve these comments along with any other Last Call comments you m= ay receive. Document: draft-ietf-marf-redaction-04 Reviewer: David L. Black Review Date: January 10, 2012 IETF LC End Date: January 18, 2011 IESG Telechat Date: January 19, 2011 Summary: This draft is on the right track but has open issues, described in= the review. This draft specifies a method for redacting information from email abuse re= ports (e.g., hiding the local part [user] of an email address), while still allow= ing correlation of the redacted information across related abuse reports from t= he same source. The draft is short, clear, and well written. There are two open issues: [1] The first open issue is the absence of security guidance to ensure that= this redaction technique effectively hides the redacted information. The redact= ion technique is to concatenate a secret string (called the "redaction key") to= the information to be redacted, apply "any hashing/digest algorithm", convert t= he output to base64 and use that base64 string to replace the redacted information. There are two important ways in which this technique could fail to effectiv= ely hide the redacted information: - The secret string may inject insufficient entropy. - The hashing/digest algorithm may be weak. To take an extreme example, if the secret string ("redaction key") consists= of a single ASCII character, and a short email local part is being redacted, the= n the output is highly vulnerable to dictionary and brute force attacks because o= nly 6 bits of entropy are added (the result may look secure, but it's not). Beyond th= is extreme example, this is a potentially real concern - e.g., applying the rule of th= umb that ASCII text contains 4-5 bits of entropy per character, the example in Appen= dix A uses a "redaction key" of "potatoes" that injects at most 40 bits of entrop= y - is that sufficient for email redaction purposes? To take a silly example, if a CRC is used as the hash with that sort of sho= rt input, the result is not particularly difficult to invert. I suggest a couple of changes: 1) Change "any hashing/digest algorithm" to require use of a secure hash, a= nd explain what is meant by "secure hash" in the security considerations sect= ion. 2) Require a minimum length of the "redaction key" string, and strongly sug= gest (SHOULD) that it be randomly generated (e.g., by running sufficient output of an entropy-rich random number generator through a base64 converter). For the latter change, figure out the amount of entropy that should be used for redaction - the recommended string length will be larger because printa= ble ASCII is not entropy-dense (at best it's good for 6 bits of entropy in each 8-bit character, and human-written text such as this message has significan= tly less). >From a pure security perspective, use of HMAC with specified secure hashes (SHA2-family) and an approach of hashing the "redaction key" down to a bina= ry key for HMAC would be a stronger approach. I suggest that authors consider approach, but there may be practical usage concerns that suggest not adopt= ing it. [2] The second open issue is absence of security considerations for the red= action key. The security considerations section needs to caution that the redacti= on key is a secret key that must be managed and protected as a secret key. Disclo= sure of a redaction key removes the redaction from all reports that used that ke= y. As part of this, guidance should be provided on when and how to change the redaction key in order to limit the effects of loss of secrecy for a single redaction key. Editorial Nit: I believe that "anonymization" is a better description of wh= at this draft is doing (as opposed to "redaction"), particularly as the result= is intended to be correlatable via string match across reports from the same s= ource. idnits 2.12.13 didn't find any nits. Thanks, --David ---------------------------------------------------- David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA=A0 01748 +1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508) 293-778= 6 david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 ---------------------------------------------------- From msk@cloudmark.com Tue Jan 10 20:40:45 2012 Return-Path: X-Original-To: gen-art@ietfa.amsl.com Delivered-To: gen-art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28D2F11E808A; Tue, 10 Jan 2012 20:40:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.577 X-Spam-Level: X-Spam-Status: No, score=-102.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R2PyupSmiN2N; Tue, 10 Jan 2012 20:40:44 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 8FBA311E8080; Tue, 10 Jan 2012 20:40:44 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by EXCH-HTCAS901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 10 Jan 2012 20:40:37 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Tue, 10 Jan 2012 20:40:43 -0800 From: "Murray S. Kucherawy" To: "david.black@emc.com" , "ietf@cybernothing.org" , "gen-art@ietf.org" , "ietf@ietf.org" Date: Tue, 10 Jan 2012 20:40:42 -0800 Thread-Topic: Gen-ART review of draft-ietf-marf-redaction-04 Thread-Index: AczQCujbMXhqirD5Sk6EB1sS2KVtOQACZtUQ Message-ID: References: <7C4DFCE962635144B8FAE8CA11D0BF1E05A7B80D63@MX14A.corp.emc.com> In-Reply-To: <7C4DFCE962635144B8FAE8CA11D0BF1E05A7B80D63@MX14A.corp.emc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "presnick@qualcomm.com" , "marf@ietf.org" Subject: Re: [Gen-art] Gen-ART review of draft-ietf-marf-redaction-04 X-BeenThere: gen-art@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "GEN-ART: General Area Review Team" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 04:40:45 -0000 > -----Original Message----- > From: david.black@emc.com [mailto:david.black@emc.com] > Sent: Tuesday, January 10, 2012 6:44 PM > To: ietf@cybernothing.org; Murray S. Kucherawy; gen-art@ietf.org; ietf@ie= tf.org > Cc: david.black@emc.com; marf@ietf.org; presnick@qualcomm.com > Subject: Gen-ART review of draft-ietf-marf-redaction-04 Hi David, thanks for the review. > [1] The first open issue is the absence of security guidance to ensure th= at this > redaction technique effectively hides the redacted information. The reda= ction > technique is to concatenate a secret string (called the "redaction key") = to the > information to be redacted, apply "any hashing/digest algorithm", convert= the output > to base64 and use that base64 string to replace the redacted information. > [...] >=20 > I suggest a couple of changes: > 1) Change "any hashing/digest algorithm" to require use of a secure hash,= and > explain what is meant by "secure hash" in the security considerations se= ction. > 2) Require a minimum length of the "redaction key" string, and strongly s= uggest > (SHOULD) that it be randomly generated (e.g., by running sufficient outp= ut > of an entropy-rich random number generator through a base64 converter). >=20 > For the latter change, figure out the amount of entropy that should be us= ed > for redaction - the recommended string length will be larger because prin= table > ASCII is not entropy-dense (at best it's good for 6 bits of entropy in ea= ch > 8-bit character, and human-written text such as this message has signific= antly > less). >=20 > From a pure security perspective, use of HMAC with specified secure hashe= s > (SHA2-family) and an approach of hashing the "redaction key" down to a bi= nary > key for HMAC would be a stronger approach. I suggest that authors conside= r > approach, but there may be practical usage concerns that suggest not > adopting it. These are all good points. My gut reaction is to say that this is all good= advice and entirely correct but probably goes a little far for the problem= space we're trying to address. Thus, my inclination is to make the follow= ing changes (subject to WG consensus): - add all of this advice to Security Considerations, with forward reference= s to it elsewhere in the document - make a SHOULD suggestion as to the minimum redaction key length (instead = of a requirement) - make a SHOULD suggestion as to the type of hash to be used (instead of a = requirement) Would those be sufficient? > [2] The second open issue is absence of security considerations for the r= edaction > key. The security considerations section needs to caution that the redac= tion key > is a secret key that must be managed and protected as a secret key. > Disclosure of a redaction key removes the redaction from all reports that= used > that key. As part of this, guidance should be provided on when and how to= change > the redaction key in order to limit the effects of loss of secrecy for a = single > redaction key. Also a good point. I don't think this is the right place to introduce advi= ce about key rotation and the like as those are well-discussed concepts, so= instead Security Considerations can simply make reference to such material= elsewhere. I'll go find some. I know there's stuff like that in RFC6376 = (DKIM) but I'm sure there are better ones. > Editorial Nit: I believe that "anonymization" is a better description of = what > this draft is doing (as opposed to "redaction"), particularly as the resu= lt is > intended to be correlatable via string match across reports from the > same source. Fair enough. We can add a sentence to that effect in the Introduction. To the MARF working group: Please let me know if the above suggestions suff= ice (reply only to the marf list, please). I will summarize and have a new= version ready to publish when LC closes, and make sure David sees it aroun= d the same time. -MSK From david.black@emc.com Tue Jan 10 23:38:58 2012 Return-Path: X-Original-To: gen-art@ietfa.amsl.com Delivered-To: gen-art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98A1A21F884A; Tue, 10 Jan 2012 23:38:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.592 X-Spam-Level: X-Spam-Status: No, score=-106.592 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hVL1roMscuMS; Tue, 10 Jan 2012 23:38:57 -0800 (PST) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id AA66921F8846; Tue, 10 Jan 2012 23:38:57 -0800 (PST) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q0B7cksC029723 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Jan 2012 02:38:47 -0500 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.222.129]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Wed, 11 Jan 2012 02:38:33 -0500 Received: from mxhub01.corp.emc.com (mxhub01.corp.emc.com [10.254.141.103]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q0B7cTgd021556; Wed, 11 Jan 2012 02:38:29 -0500 Received: from mx14a.corp.emc.com ([169.254.1.99]) by mxhub01.corp.emc.com ([10.254.141.103]) with mapi; Wed, 11 Jan 2012 02:38:28 -0500 From: To: , , , Date: Wed, 11 Jan 2012 02:38:26 -0500 Thread-Topic: Gen-ART review of draft-ietf-marf-redaction-04 Thread-Index: AczQCujbMXhqirD5Sk6EB1sS2KVtOQACZtUQAAZ2BJA= Message-ID: <7C4DFCE962635144B8FAE8CA11D0BF1E05A7B80D8B@MX14A.corp.emc.com> References: <7C4DFCE962635144B8FAE8CA11D0BF1E05A7B80D63@MX14A.corp.emc.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Cc: presnick@qualcomm.com, marf@ietf.org Subject: Re: [Gen-art] Gen-ART review of draft-ietf-marf-redaction-04 X-BeenThere: gen-art@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "GEN-ART: General Area Review Team" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 07:38:58 -0000 Hi Murray, Thanks for the quick response. > These are all good points. My gut reaction is to say that this is all go= od advice and entirely > correct but probably goes a little far for the problem space we're trying= to address. =20 That sounds reasonable to me, and I like John Levine's suggestion to add ma= terial to explain more about the level of security that is appropriate for this problem space= and why. In light of such an explanation, an HMAC-based mechanism could well be overkill. > - make a SHOULD suggestion as to the minimum redaction key length (instea= d of a requirement) > - make a SHOULD suggestion as to the type of hash to be used (instead of = a requirement) I have a hard time believing that the examples used in the review ("a" as t= he redaction key, CRC as the hash) are ever acceptable, and for that reason, I think a c= ouple of MUSTs would be in order to prohibit that sort of nonsense. In particular: - I think there ought to be a MUST minimum length requirement on the redaction key string to prevent really short ones. - I think use of a secure hash ought to be a MUST to prevent use of CRC and other bad ideas. That could be accompanied by additional guidance that may or may not be "SH= OULDs", e.g., suggest a SHA2 hash as a good secure hash, suggest use of a longer string t= han the minimum requirement. > > [2] The second open issue is absence of security considerations for the= redaction > > key. The security considerations section needs to caution that the red= action key > > is a secret key that must be managed and protected as a secret key. > > Disclosure of a redaction key removes the redaction from all reports th= at used > > that key. As part of this, guidance should be provided on when and how = to change > > the redaction key in order to limit the effects of loss of secrecy for = a single > > redaction key. > > Also a good point. I don't think this is the right place to introduce ad= vice about key rotation and > the like as those are well-discussed concepts, so instead Security Consid= erations can simply make > reference to such material elsewhere. I'll go find some. I know there's= stuff like that in RFC6376 > (DKIM) but I'm sure there are better ones. That would be fine - introducing the concept of key rotation as a means to = reduce the impact of key compromise accompanied by a reference to a longer explanation elsewhere see= ms reasonable. Thanks, --David > -----Original Message----- > From: Murray S. Kucherawy [mailto:msk@cloudmark.com] > Sent: Tuesday, January 10, 2012 11:41 PM > To: Black, David; ietf@cybernothing.org; gen-art@ietf.org; ietf@ietf.org > Cc: marf@ietf.org; presnick@qualcomm.com > Subject: RE: Gen-ART review of draft-ietf-marf-redaction-04 >=20 > > -----Original Message----- > > From: david.black@emc.com [mailto:david.black@emc.com] > > Sent: Tuesday, January 10, 2012 6:44 PM > > To: ietf@cybernothing.org; Murray S. Kucherawy; gen-art@ietf.org; ietf@= ietf.org > > Cc: david.black@emc.com; marf@ietf.org; presnick@qualcomm.com > > Subject: Gen-ART review of draft-ietf-marf-redaction-04 >=20 > Hi David, thanks for the review. >=20 > > [1] The first open issue is the absence of security guidance to ensure = that this > > redaction technique effectively hides the redacted information. The re= daction > > technique is to concatenate a secret string (called the "redaction key"= ) to the > > information to be redacted, apply "any hashing/digest algorithm", conve= rt the output > > to base64 and use that base64 string to replace the redacted informatio= n. > > [...] > > > > I suggest a couple of changes: > > 1) Change "any hashing/digest algorithm" to require use of a secure has= h, and > > explain what is meant by "secure hash" in the security considerations = section. > > 2) Require a minimum length of the "redaction key" string, and strongly= suggest > > (SHOULD) that it be randomly generated (e.g., by running sufficient ou= tput > > of an entropy-rich random number generator through a base64 converter)= . > > > > For the latter change, figure out the amount of entropy that should be = used > > for redaction - the recommended string length will be larger because pr= intable > > ASCII is not entropy-dense (at best it's good for 6 bits of entropy in = each > > 8-bit character, and human-written text such as this message has signif= icantly > > less). > > > > From a pure security perspective, use of HMAC with specified secure has= hes > > (SHA2-family) and an approach of hashing the "redaction key" down to a = binary > > key for HMAC would be a stronger approach. I suggest that authors consi= der > > approach, but there may be practical usage concerns that suggest not > > adopting it. >=20 > These are all good points. My gut reaction is to say that this is all go= od advice and entirely > correct but probably goes a little far for the problem space we're trying= to address. Thus, my > inclination is to make the following changes (subject to WG consensus): >=20 > - add all of this advice to Security Considerations, with forward referen= ces to it elsewhere in the > document > - make a SHOULD suggestion as to the minimum redaction key length (instea= d of a requirement) > - make a SHOULD suggestion as to the type of hash to be used (instead of = a requirement) >=20 > Would those be sufficient? >=20 > > [2] The second open issue is absence of security considerations for the= redaction > > key. The security considerations section needs to caution that the red= action key > > is a secret key that must be managed and protected as a secret key. > > Disclosure of a redaction key removes the redaction from all reports th= at used > > that key. As part of this, guidance should be provided on when and how = to change > > the redaction key in order to limit the effects of loss of secrecy for = a single > > redaction key. >=20 > Also a good point. I don't think this is the right place to introduce ad= vice about key rotation and > the like as those are well-discussed concepts, so instead Security Consid= erations can simply make > reference to such material elsewhere. I'll go find some. I know there's= stuff like that in RFC6376 > (DKIM) but I'm sure there are better ones. >=20 > > Editorial Nit: I believe that "anonymization" is a better description o= f what > > this draft is doing (as opposed to "redaction"), particularly as the re= sult is > > intended to be correlatable via string match across reports from the > > same source. >=20 > Fair enough. We can add a sentence to that effect in the Introduction. >=20 > To the MARF working group: Please let me know if the above suggestions su= ffice (reply only to the marf > list, please). I will summarize and have a new version ready to publish = when LC closes, and make sure > David sees it around the same time. >=20 > -MSK From paul.hoffman@vpnc.org Wed Jan 11 11:02:48 2012 Return-Path: X-Original-To: gen-art@ietfa.amsl.com Delivered-To: gen-art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E70B921F852F; Wed, 11 Jan 2012 11:02:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xmsPyCy0PuVz; Wed, 11 Jan 2012 11:02:48 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 4BCBB21F84D4; Wed, 11 Jan 2012 11:02:48 -0800 (PST) Received: from sn87.proper.com (sn87.proper.com [75.101.18.87]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id q0BJ2kd0059299 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 11 Jan 2012 12:02:47 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Paul Hoffman In-Reply-To: <7C4DFCE962635144B8FAE8CA11D0BF1E05A7B80D63@MX14A.corp.emc.com> Date: Wed, 11 Jan 2012 11:02:45 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <636DA6C1-48E5-4A3D-BEE8-B6AD46E7DF49@vpnc.org> References: <7C4DFCE962635144B8FAE8CA11D0BF1E05A7B80D63@MX14A.corp.emc.com> To: IETF Discussion X-Mailer: Apple Mail (2.1251.1) Cc: gen-art@ietf.org, marf@ietf.org Subject: Re: [Gen-art] Gen-ART review of draft-ietf-marf-redaction-04 X-BeenThere: gen-art@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "GEN-ART: General Area Review Team" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 19:02:49 -0000 On Jan 10, 2012, at 6:44 PM, = wrote: > [1] The first open issue is the absence of security guidance to ensure = that this > redaction technique effectively hides the redacted information. The = redaction > technique is to concatenate a secret string (called the "redaction = key") to the > information to be redacted, apply "any hashing/digest algorithm", = convert the output > to base64 and use that base64 string to replace the redacted = information. >=20 > There are two important ways in which this technique could fail to = effectively hide > the redacted information: > - The secret string may inject insufficient entropy. > - The hashing/digest algorithm may be weak. >=20 > To take an extreme example, if the secret string ("redaction key") = consists of a > single ASCII character, and a short email local part is being = redacted, then the > output is highly vulnerable to dictionary and brute force attacks = because only 6 bits > of entropy are added (the result may look secure, but it's not). = Beyond this extreme > example, this is a potentially real concern - e.g., applying the rule = of thumb that > ASCII text contains 4-5 bits of entropy per character, the example in = Appendix A > uses a "redaction key" of "potatoes" that injects at most 40 bits of = entropy - > is that sufficient for email redaction purposes? >=20 > To take a silly example, if a CRC is used as the hash with that sort = of short input, > the result is not particularly difficult to invert. >=20 > I suggest a couple of changes: > 1) Change "any hashing/digest algorithm" to require use of a secure = hash, and > explain what is meant by "secure hash" in the security = considerations section. Simply saying "any hash algorithm listed in [FIPS180-3]" is precise and = sufficient. > 2) Require a minimum length of the "redaction key" string, and = strongly suggest > (SHOULD) that it be randomly generated (e.g., by running = sufficient output > of an entropy-rich random number generator through a base64 = converter). Proposal: "The redaction key SHOULD be based on at least 64 bits of = pseudo-random input that is converted to base64". > [2] The second open issue is absence of security considerations for = the redaction > key. The security considerations section needs to caution that the = redaction key > is a secret key that must be managed and protected as a secret key. = Disclosure > of a redaction key removes the redaction from all reports that used = that key. Agree. > As part of this, guidance should be provided on when and how to change = the > redaction key in order to limit the effects of loss of secrecy for a = single > redaction key. Disagree, given that we have absolutely no idea how systems that use = this will work operationally. Simply telling them "if it is no longer = secret, you're hosed" is sufficient. --Paul Hoffman From sm@resistor.net Wed Jan 11 11:50:41 2012 Return-Path: X-Original-To: gen-art@ietfa.amsl.com Delivered-To: gen-art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6063E21F84F5; Wed, 11 Jan 2012 11:50:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0on2hh3+H8cF; Wed, 11 Jan 2012 11:50:38 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EDF821F84F3; Wed, 11 Jan 2012 11:50:38 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q0BJoTsG014962; Wed, 11 Jan 2012 11:50:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1326311436; i=@resistor.net; bh=P/QL1U+E812ocBWJFlglwAiQx/51Q3iWIN49ZNK0JJ8=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=vH84mbHasBOfd1qJ41w0Uj4cFl/swBxBc0Qd/Y4EPtwix9vcNIN76Ez5dYNdwypd5 sgqBIQDsjPsW7wXLhdpAqSuB+abo7eNzV8YlnNPHqfyO71Mq0jnTfymIWgl7/jFeRf w7e68PP6yekAVJRawnLfO3loEnrD/NFlMydsgWjc= Message-Id: <6.2.5.6.2.20120111112546.0c105678@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 11 Jan 2012 11:50:20 -0800 To: david.black@emc.com From: SM In-Reply-To: <7C4DFCE962635144B8FAE8CA11D0BF1E05A7B80D63@MX14A.corp.emc. com> References: <7C4DFCE962635144B8FAE8CA11D0BF1E05A7B80D63@MX14A.corp.emc.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: gen-art@ietf.org, ietf@ietf.org, marf@ietf.org Subject: Re: [Gen-art] Gen-ART review of draft-ietf-marf-redaction-04 X-BeenThere: gen-art@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "GEN-ART: General Area Review Team" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 19:50:41 -0000 Hi David, At 18:44 10-01-2012, david.black@emc.com wrote: >I am the assigned Gen-ART reviewer for this draft. For background on >Gen-ART, please I appreciate that you have spent your time and effort in performing the review. I find the review useful. > From a pure security perspective, use of HMAC with specified secure hashes >(SHA2-family) and an approach of hashing the "redaction key" down to a binary >key for HMAC would be a stronger approach. I suggest that authors consider >approach, but there may be practical usage concerns that suggest >not adopting it. > >[2] The second open issue is absence of security considerations for >the redaction >key. The security considerations section needs to caution that the >redaction key >is a secret key that must be managed and protected as a secret >key. Disclosure >of a redaction key removes the redaction from all reports that used that key. >As part of this, guidance should be provided on when and how to change the >redaction key in order to limit the effects of loss of secrecy for a single >redaction key. The comments are from a security perspective. To be candid, redaction is silly as the email folks know how to get around that. The secret key does not even have to be broken; a cookie in the message would get you the information you want. The cost of preserving the secrecy is not worth it in my opinion. Regards, -sm From david.black@emc.com Wed Jan 11 12:52:16 2012 Return-Path: X-Original-To: gen-art@ietfa.amsl.com Delivered-To: gen-art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C594321F8533; Wed, 11 Jan 2012 12:52:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.592 X-Spam-Level: X-Spam-Status: No, score=-106.592 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bHtTnlnLbzDm; Wed, 11 Jan 2012 12:52:16 -0800 (PST) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id DA0BD21F85D5; Wed, 11 Jan 2012 12:52:15 -0800 (PST) Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q0BKqAAZ025206 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Jan 2012 15:52:12 -0500 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.222.226]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor); Wed, 11 Jan 2012 15:52:02 -0500 Received: from mxhub21.corp.emc.com (mxhub21.corp.emc.com [128.222.70.133]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q0BKq12u024049; Wed, 11 Jan 2012 15:52:01 -0500 Received: from mxhub39.corp.emc.com (128.222.70.106) by mxhub21.corp.emc.com (128.222.70.133) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 11 Jan 2012 15:52:01 -0500 Received: from mx14a.corp.emc.com ([169.254.1.99]) by mxhub39.corp.emc.com ([128.222.70.106]) with mapi; Wed, 11 Jan 2012 15:52:01 -0500 From: To: Date: Wed, 11 Jan 2012 15:51:58 -0500 Thread-Topic: Gen-ART review of draft-ietf-marf-redaction-04 Thread-Index: AczQmns3tJWBjqmEQUeESbIBILYfNwABuHzw Message-ID: <7C4DFCE962635144B8FAE8CA11D0BF1E05A7B8106C@MX14A.corp.emc.com> References: <7C4DFCE962635144B8FAE8CA11D0BF1E05A7B80D63@MX14A.corp.emc.com> <6.2.5.6.2.20120111112546.0c105678@resistor.net> In-Reply-To: <6.2.5.6.2.20120111112546.0c105678@resistor.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Cc: gen-art@ietf.org, ietf@ietf.org, marf@ietf.org Subject: Re: [Gen-art] Gen-ART review of draft-ietf-marf-redaction-04 X-BeenThere: gen-art@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "GEN-ART: General Area Review Team" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 20:52:16 -0000 Hi, Thanks for the response - I appreciate the perspective. > The comments are from a security perspective. To be candid, > redaction is silly as the email folks know how to get around > that. The secret key does not even have to be broken; a cookie in > the message would get you the information you want. The cost of > preserving the secrecy is not worth it in my opinion. At a minimum, I like John Levine's suggestion that the draft explain the level of security required for redaction in practice. Such an explanation could help illuminate whether the secure hash (the example in the draft uses SHA-1) is for obfuscation purposes vs. actual security. Absent such an explanation, I saw the use of a secure hash and inferred the existence of actual security requirements. If that was an incorrect inference, then text should be added to the draft to avoid having other readers make similarly incorrect inferences. Thanks, --David > -----Original Message----- > From: SM [mailto:sm@resistor.net] > Sent: Wednesday, January 11, 2012 2:50 PM > To: Black, David > Cc: marf@ietf.org; gen-art@ietf.org; ietf@ietf.org > Subject: Re: Gen-ART review of draft-ietf-marf-redaction-04 >=20 > Hi David, > At 18:44 10-01-2012, david.black@emc.com wrote: > >I am the assigned Gen-ART reviewer for this draft. For background on > >Gen-ART, please >=20 > I appreciate that you have spent your time and effort in performing > the review. I find the review useful. >=20 > > From a pure security perspective, use of HMAC with specified secure has= hes > >(SHA2-family) and an approach of hashing the "redaction key" down to a b= inary > >key for HMAC would be a stronger approach. I suggest that authors consid= er > >approach, but there may be practical usage concerns that suggest > >not adopting it. > > > >[2] The second open issue is absence of security considerations for > >the redaction > >key. The security considerations section needs to caution that the > >redaction key > >is a secret key that must be managed and protected as a secret > >key. Disclosure > >of a redaction key removes the redaction from all reports that used that= key. > >As part of this, guidance should be provided on when and how to change t= he > >redaction key in order to limit the effects of loss of secrecy for a sin= gle > >redaction key. >=20 > The comments are from a security perspective. To be candid, > redaction is silly as the email folks know how to get around > that. The secret key does not even have to be broken; a cookie in > the message would get you the information you want. The cost of > preserving the secrecy is not worth it in my opinion. >=20 > Regards, > -sm >=20 From sm@resistor.net Wed Jan 11 13:16:38 2012 Return-Path: X-Original-To: gen-art@ietfa.amsl.com Delivered-To: gen-art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD24011E80B2; Wed, 11 Jan 2012 13:16:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fIB6udQNS7r4; Wed, 11 Jan 2012 13:16:38 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3770411E8074; Wed, 11 Jan 2012 13:16:38 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q0BLGUVa005928; Wed, 11 Jan 2012 13:16:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1326316596; i=@resistor.net; bh=2xi/6d3QoAOBAkFfR2WvFMhLgvSfgM2Yj3s0C7zLbPg=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=aMCSzqf+Wj8V7ClYdw0ZjUo+bVWQTQY4Gh3whtiJf9NIOXB6T3fTyMoa9WENY6CZD uLpQ++KXLDeByzeoFN0t44yWYFSkDlEIutGUClSUxaA8qArESqoyKaIibtNRPfzUf6 SFC/cmstk/bEqYQkI/v1bGkZO1wgaMkITbCEY6WU= Message-Id: <6.2.5.6.2.20120111130905.0c07cff0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 11 Jan 2012 13:15:12 -0800 To: david.black@emc.com From: SM In-Reply-To: <7C4DFCE962635144B8FAE8CA11D0BF1E05A7B8106C@MX14A.corp.emc. com> References: <7C4DFCE962635144B8FAE8CA11D0BF1E05A7B80D63@MX14A.corp.emc.com> <6.2.5.6.2.20120111112546.0c105678@resistor.net> <7C4DFCE962635144B8FAE8CA11D0BF1E05A7B8106C@MX14A.corp.emc.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: gen-art@ietf.org, marf@ietf.org Subject: Re: [Gen-art] Gen-ART review of draft-ietf-marf-redaction-04 X-BeenThere: gen-art@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "GEN-ART: General Area Review Team" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 21:16:39 -0000 Hi David, At 12:51 11-01-2012, david.black@emc.com wrote: >At a minimum, I like John Levine's suggestion that the draft explain >the level of security required for redaction in practice. Such an >explanation could help illuminate whether the secure hash (the >example in the draft uses SHA-1) is for obfuscation purposes >vs. actual security. It would help to have an explanation along the line of John Levine's suggestion. >Absent such an explanation, I saw the use of a secure hash and inferred >the existence of actual security requirements. If that was an incorrect >inference, then text should be added to the draft to avoid having >other readers make similarly incorrect inferences. Agreed. Regards, -sm From miguel.a.garcia@ericsson.com Thu Jan 12 03:41:45 2012 Return-Path: X-Original-To: gen-art@ietfa.amsl.com Delivered-To: gen-art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6089021F85A7 for ; Thu, 12 Jan 2012 03:41:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.499 X-Spam-Level: X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dmLF4nZqF5m6 for ; Thu, 12 Jan 2012 03:41:44 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id E60EA21F85A5 for ; Thu, 12 Jan 2012 03:41:40 -0800 (PST) X-AuditID: c1b4fb39-b7b3eae00000252a-87-4f0ec6f36160 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.115.96]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 9B.32.09514.3F6CE0F4; Thu, 12 Jan 2012 12:41:39 +0100 (CET) Received: from [159.107.24.157] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.137.0; Thu, 12 Jan 2012 12:41:37 +0100 Message-ID: <4F0EC6F0.2010303@ericsson.com> Date: Thu, 12 Jan 2012 12:41:36 +0100 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: jiangsheng@huawei.com, drc@cloudflare.com, Brian E Carpenter , Ralph Droms Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Cc: General Area Review Team Subject: [Gen-art] Gen-ART review of draft-jiang-a6-to-historic-00.txt X-BeenThere: gen-art@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "GEN-ART: General Area Review Team" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2012 11:41:45 -0000 I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft. For background on Gen-ART, please see the FAQ at Please resolve these comments along with any other comments you may receive. Document: draft-jiang-a6-to-historic-00.txt Reviewer: Miguel Garcia Review Date: 2012-01-12 IETF LC End Date: 2012-01-18 IESG Telechat date: 2012-01-19 Summary: The document is ready for publication as Informational RFC. The document is clear. The are no issues. /Miguel -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From mahoney@nostrum.com Thu Jan 12 17:07:31 2012 Return-Path: X-Original-To: gen-art@ietfa.amsl.com Delivered-To: gen-art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 918F411E8091 for ; Thu, 12 Jan 2012 17:07:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8g9xRGEZo0ak for ; Thu, 12 Jan 2012 17:07:31 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 155A211E8073 for ; Thu, 12 Jan 2012 17:07:31 -0800 (PST) Received: from A-Jean-Mahoneys-MacBook-Pro.local (pool-173-57-95-103.dllstx.fios.verizon.net [173.57.95.103]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q0D17UO0077321 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Thu, 12 Jan 2012 19:07:30 -0600 (CST) (envelope-from mahoney@nostrum.com) Message-ID: <4F0F83D2.8070401@nostrum.com> Date: Thu, 12 Jan 2012 19:07:30 -0600 From: "A. Jean Mahoney" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: gen-art@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 173.57.95.103 is authenticated by a trusted mechanism) Subject: [Gen-art] A *new* batch of IETF LC reviews - 2012-01-12 X-BeenThere: gen-art@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "GEN-ART: General Area Review Team" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2012 01:07:31 -0000 Hi all, Here's the link to the new LC assignments: http://wiki.tools.ietf.org/dav/genart/reviewers-120112-lc.html The assignments are captured in the spreadsheets: http://wiki.tools.ietf.org/dav/genart/gen-art.html http://wiki.tools.ietf.org/dav/genart/gen-art-by-reviewer.html And I have made the assignments in the review tool: http://art.tools.ietf.org/tools/art/genart/ The standard template is included below. Thanks, Jean ------------------------------------------------------------------- I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at . Please resolve these comments along with any other Last Call comments you may receive. Document: Reviewer: Review Date: IETF LC End Date: IESG Telechat date: (if known) Summary: Major issues: Minor issues: Nits/editorial comments: From mahoney@nostrum.com Thu Jan 12 17:11:02 2012 Return-Path: X-Original-To: gen-art@ietfa.amsl.com Delivered-To: gen-art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98A4B21F8530 for ; Thu, 12 Jan 2012 17:11:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dqSlv5OhBRxJ for ; Thu, 12 Jan 2012 17:11:02 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id AABE521F8504 for ; Thu, 12 Jan 2012 17:11:01 -0800 (PST) Received: from A-Jean-Mahoneys-MacBook-Pro.local (pool-173-57-95-103.dllstx.fios.verizon.net [173.57.95.103]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q0D1B0Z0077920 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Thu, 12 Jan 2012 19:11:01 -0600 (CST) (envelope-from mahoney@nostrum.com) Message-ID: <4F0F84A4.5040603@nostrum.com> Date: Thu, 12 Jan 2012 19:11:00 -0600 From: "A. Jean Mahoney" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: gen-art@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 173.57.95.103 is authenticated by a trusted mechanism) Subject: [Gen-art] Assignments for the 2012-01-19 telechat X-BeenThere: gen-art@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "GEN-ART: General Area Review Team" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2012 01:11:02 -0000 Hi all, Assignments for the telechat can be found here: http://wiki.tools.ietf.org/dav/genart/reviewers-120119-telechat.html With the updated spreadsheets: http://wiki.tools.ietf.org/dav/genart/gen-art.html http://wiki.tools.ietf.org/dav/genart/gen-art-by-reviewer.html I've also updated the review tool: http://art.tools.ietf.org/tools/art/genart/ For your convenience, the review boilerplate template is included below. Note that reviews should ideally be posted to the gen-art mailing list by COB on Tuesday: http://wiki.tools.ietf.org/area/gen/trac/wiki/ Jean ------------------------------------------------------------------- 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: Reviewer: Review Date: IETF LC End Date: IESG Telechat date: (if known) Summary: Major issues: Minor issues: Nits/editorial comments: From ron.even.tlv@gmail.com Thu Jan 12 23:20:25 2012 Return-Path: X-Original-To: gen-art@ietfa.amsl.com Delivered-To: gen-art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 251AB21F84D7; Thu, 12 Jan 2012 23:20:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rNs6z1fujk16; Thu, 12 Jan 2012 23:20:24 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id B4D5A21F84CD; Thu, 12 Jan 2012 23:20:22 -0800 (PST) Received: by eeit10 with SMTP id t10so22335eei.31 for ; Thu, 12 Jan 2012 23:20:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :content-language:thread-index; bh=MTzSjehSdqJWkFmzv7sEq65Kjbz2vcphhWhbeNQWGLk=; b=fFnyTSGfYIgx53SYS5JGuMSM3GlhWQXPmg/tI/a2IT8Agv9eZo/ZQfPaRYWLyhhSAN KJO/LGnie6UrhTR637jYOMmjEIjgSqdpGbdj9tRXbbpQsC5o+UBN5ZL9yuXq5/qCGuwe NmkO6Lf8eX8isFPGQyNj/3qy9aswObFftwcd4= Received: by 10.213.32.208 with SMTP id e16mr338191ebd.145.1326439221792; Thu, 12 Jan 2012 23:20:21 -0800 (PST) Received: from windows8d787f9 (bzq-79-180-198-96.red.bezeqint.net. [79.180.198.96]) by mx.google.com with ESMTPS id x43sm25934136eef.8.2012.01.12.23.20.18 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 12 Jan 2012 23:20:19 -0800 (PST) From: "Roni Even" To: "'Kireeti Kompella'" References: <4e6757ab.87c5e30a.061b.0446@mx.google.com> In-Reply-To: Date: Fri, 13 Jan 2012 09:16:51 +0200 Message-ID: <4f0fdb33.c3630e0a.7550.fffff20b@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Content-language: en-us Thread-Index: Acx0phniNB2Aj/ikRoOGlEj3bxY2RRdHP47g Cc: draft-kompella-l2vpn-l2vpn.all@tools.ietf.org, gen-art@ietf.org, 'IETF-Discussion list' Subject: Re: [Gen-art] Gen-ART LC review of draft-kompella-l2vpn-l2vpn-07 X-BeenThere: gen-art@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "GEN-ART: General Area Review Team" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2012 07:20:25 -0000 Hi, I looked at the 08 version and the major issues are addressed. What about minor issue number 3? Roni Even > -----Original Message----- > From: Kireeti Kompella [mailto:kireeti@juniper.net] > Sent: Friday, September 16, 2011 10:23 PM > To: Roni Even > Cc: Kireeti Kompella; draft-kompella-l2vpn-l2vpn.all@tools.ietf.org; > gen-art@ietf.org; IETF-Discussion list > Subject: Re: Gen-ART LC review of draft-kompella-l2vpn-l2vpn-07 > > Hi Roni, > > On Sep 7, 2011, at 4:37 , Roni Even wrote: > > > I am the assigned Gen-ART reviewer for this draft. For background on > Gen-ART, please see the FAQ at > . > > Thanks! > > > Please resolve these comments along with any other Last Call comments > you may receive. > > > > Document: draft-kompella-l2vpn-l2vpn-07 > > Reviewer: Roni Even > > Review Date: 2011-9-7 > > IETF LC End Date: 2011-9-27 > > IESG Telechat date: > > > > Summary: This draft is not ready for publication as an informational > RFC. > > > > Major issues: > > > > The IANA considerations section says: > > "the values already allocated are in Table 1 of Section 4. The > allocation policy for new entries up to and including value 127 is > "Standards Action". The allocation policy for values 128 through 251 > is "First Come First Served". The values from 252 through 255 are for > "Experimental Use"." > > Standards Action will be changed to Expert Review. > > > Yet this is document is intended for Informational status which > contradict the standard action. This is also true for the second > registry defined. > > > > Is this document really an Informational one? > > My only comment is that it is not Historic. > > > Minor issues: > > > > 1. In section 1.2.2 "Since "traditional" Layer 2 VPNs (i.e., > real Frame Relay circuits connecting sites) are indistinguishable from > tunnel-based VPNs from the customer's point-of-view, migrating from > one to the other raises few issues." What are the few issues? > > A subtlety: "few issues" means not many, not deep; it's a careful way > of saying, "just about no issues". "A few issues" would require > elaboration. > > > 2. In section 4 "L2VPN TLVs can be added to extend the > information carried in the NLRI, using the format shown in Figure 2". > How is the TLV carried in the NLRI, in which field, section 4.1 only > talk about the structure of the TLV. > > I'll take the figure from 3.2.2 of RFC 4761 and show where the TLVs go. > > > 3. Section 4.2 refers to section 4 but I am not sure where this > mechanism in section 4 is. > > Will clarify. > > > > > > > > > > > > > Nits/editorial comments: > > > > 1. Section 3.1 is called network topology but the whole text is > an example of a network topology. Maybe the title should be "Example of > a network toplogy". > > Sure. > > > 2. Section 5 starts with "As defined so far in the document .." > But the using IP only is already discussed in previous sections. > > Do you have a suggestion for rewording? > > Thanks, > Kireeti. > > > > > > > > From barryleiba.mailing.lists@gmail.com Fri Jan 13 07:13:56 2012 Return-Path: X-Original-To: gen-art@ietfa.amsl.com Delivered-To: gen-art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0505C21F84CD; Fri, 13 Jan 2012 07:13:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.721 X-Spam-Level: X-Spam-Status: No, score=-102.721 tagged_above=-999 required=5 tests=[AWL=0.256, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2sXtoMO3mISn; Fri, 13 Jan 2012 07:13:55 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4D5A021F845F; Fri, 13 Jan 2012 07:13:55 -0800 (PST) Received: by yenr11 with SMTP id r11so308458yen.31 for ; Fri, 13 Jan 2012 07:13:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=kCQwa5isQj/RaVT7dmuintVTJEeJRMRSWg4n9MEp+p8=; b=g7nSc5vCgJMfKRnK6V45ALKPWuSSasl9+ok6WzyDSMJdE+vRAyJhBvec/Ut5jo7yUh nxESo/NgqZF+Iz6wPJS649CjoSnDf3kNIetP2PAZG6p3djeYVIK5iFD8txzm+rCoWs7D yEtaQAnTU6tRcp8UJa8p3HH/yUzvrJmL+rH4I= MIME-Version: 1.0 Received: by 10.236.152.35 with SMTP id c23mr2020878yhk.58.1326467634850; Fri, 13 Jan 2012 07:13:54 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.147.114.13 with HTTP; Fri, 13 Jan 2012 07:13:49 -0800 (PST) In-Reply-To: References: <2FF53820-1728-4FDE-843A-19E61CBB795D@nostrum.com> Date: Fri, 13 Jan 2012 10:13:49 -0500 X-Google-Sender-Auth: VMYjuaVuR_GATWOWG6bl3jAQgYc Message-ID: From: Barry Leiba To: Aaron Stone Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Ben Campbell , "gen-art@ietf.org Review Team" , Sieve mailing list Subject: Re: [Gen-art] [sieve] Gen-ART Last Call Review of draft-ietf-sieve-include-13 X-BeenThere: gen-art@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "GEN-ART: General Area Review Team" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2012 15:13:56 -0000 >>> -- section 3.1, paragraph 4: "Implementations MUST NOT generate errors = for >>> recursive inclusions at upload time, as this would force an upload orde= ring >>> requirement upon script authors / generators. =A0However, if an active = script >>> is replaced with a faulty script and would remain the active script, an >>> error MUST be generated and the upload MUST fail." >>> >>> These two statements seem contradictory on a quick reading. =A0In >>> particular, how can the latter assertion avoid an upload ordering >>> requirement? Or do you mean faulty in some way other than being recursi= ve? >> >> If you're replacing an active script, it has to be correct all the time,= and >> uploads are atomic only on a per-script basis. There's a risk that if yo= u're >> uploading a set of scripts that include one another, at some intermediat= e >> stage while some scripts are uploaded but not others, they are in an inv= alid >> state. The managesieve spec says that scripts must be validated at uploa= d >> time. The language above is trying to say that you can upload all of the >> scripts that may include one another in any order without generating err= ors >> immediately, however, if you're replacing an active script or a script >> included by the active script, then you DO have to upload a correct scri= pt >> right from the get-go. >> >> Is this just a question of whether the script(s) are replacing active >> scripts? That is, the license to create a transient invalid state is >> suspended if if you are replacing an active script? If so, how would one= go >> about updating a set of linked scripts when one or more of them replace >> active scripts? Should one somehow deactivate the old ones, load all the >> scripts, then activate them? > > Having written this out, I don't recall how an implementation would > handle this. I haven't had luck tracking down maling list discussion > on the topic. I'll have to chase up on this. I don't think this is a real problem; the text just needs a little tweaking. Errors should still be generated at upload time for any detectable script errors OTHER THAN recursion. What this is meant to deal with is a situation where, say, we have this: main includes sub-a sub-a includes sub-b sub-b includes sub-c ...and we want to rewrite things and change the structure thus: main includes sub-a main includes sub-c sub-c includes sub-b [sub-b no longer includes sub-c] This would require that we update sub-b *before* we update sub-c, or else we'd get an error at upload time. The text is meant to block the recursion error, so we can update the scripts in any order. However, if the script gets run in the middle of the updates and we hit a recursion situation, we WILL get a runtime error. That's all that text is meant to do. That said, it would be wise for implementations to provide a way to do an atomic update of a set of scripts, because, clearly, multiple scrips in some indeterminate intermediate upload state could do very weird (and perhaps bad) things, even if no errors are generated during their execution. I think this isn't a protocol requirement, but a quality-of-implementation issue. But I do think the document could have a paragraph discussing this, and warning of the consequences. Barry, document shepherd From ben@nostrum.com Fri Jan 13 08:58:30 2012 Return-Path: X-Original-To: gen-art@ietfa.amsl.com Delivered-To: gen-art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3258F21F864E; Fri, 13 Jan 2012 08:58:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.29 X-Spam-Level: X-Spam-Status: No, score=-102.29 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X3t0BT8EHLtw; Fri, 13 Jan 2012 08:58:29 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id B47F921F8645; Fri, 13 Jan 2012 08:58:29 -0800 (PST) Received: from dn3-53.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q0DGwN7t020153 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 13 Jan 2012 10:58:24 -0600 (CST) (envelope-from ben@nostrum.com) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=windows-1252 From: Ben Campbell In-Reply-To: Date: Fri, 13 Jan 2012 10:58:28 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2FF53820-1728-4FDE-843A-19E61CBB795D@nostrum.com> To: Barry Leiba X-Mailer: Apple Mail (2.1251.1) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: Sieve mailing list , "gen-art@ietf.org Review Team" , Aaron Stone Subject: Re: [Gen-art] [sieve] Gen-ART Last Call Review of draft-ietf-sieve-include-13 X-BeenThere: gen-art@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "GEN-ART: General Area Review Team" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2012 16:58:30 -0000 On Jan 13, 2012, at 9:13 AM, Barry Leiba wrote: [=85] >=20 > I think this isn't a protocol requirement, but a > quality-of-implementation issue. But I do think the document could > have a paragraph discussing this, and warning of the consequences. I concur that this is not so much a protocol issue as a documentation = issue. I did not mean to imply things were broken; just that I found the = intent to be unclear. I think such a paragraph would likely solve the = issue. Thanks! Ben. From kireeti@juniper.net Fri Jan 13 09:37:39 2012 Return-Path: X-Original-To: gen-art@ietfa.amsl.com Delivered-To: gen-art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7157421F852B; Fri, 13 Jan 2012 09:37:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jqpG84ua9HZI; Fri, 13 Jan 2012 09:37:38 -0800 (PST) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by ietfa.amsl.com (Postfix) with ESMTP id 59B4C21F867F; Fri, 13 Jan 2012 09:37:38 -0800 (PST) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP ID DSNKTxBr2WfBJ5Cmgt4HpV0fp7fBg4LWGUeV@postini.com; Fri, 13 Jan 2012 09:37:38 PST Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Fri, 13 Jan 2012 09:35:42 -0800 From: Kireeti Kompella To: Roni Even Date: Fri, 13 Jan 2012 09:35:41 -0800 Thread-Topic: Gen-ART LC review of draft-kompella-l2vpn-l2vpn-07 Thread-Index: AczSGcWVZIGwNpfQRl2KXMDU0zFrGQ== Message-ID: <3BE55A51-26E0-415F-90C5-AF1905A91237@juniper.net> References: <4e6757ab.87c5e30a.061b.0446@mx.google.com> <4f0fdb33.c3630e0a.7550.fffff20b@mx.google.com> In-Reply-To: <4f0fdb33.c3630e0a.7550.fffff20b@mx.google.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Kireeti Kompella , "draft-kompella-l2vpn-l2vpn.all@tools.ietf.org" , "gen-art@ietf.org" , IETF-Discussion list Subject: Re: [Gen-art] Gen-ART LC review of draft-kompella-l2vpn-l2vpn-07 X-BeenThere: gen-art@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "GEN-ART: General Area Review Team" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2012 17:37:39 -0000 On Jan 12, 2012, at 23:16 , Roni Even wrote: > Hi, > I looked at the 08 version and the major issues are addressed. > What about minor issue number 3? Good point! I will fix (as Stewart suggests, maybe just remove the referen= ce). To your minor issue (2), I've clarified the structure. Do you still want t= o see how it fits into the NLRI? Thanks, Kireeti. > Roni Even >=20 >> -----Original Message----- >> From: Kireeti Kompella [mailto:kireeti@juniper.net] >> Sent: Friday, September 16, 2011 10:23 PM >> To: Roni Even >> Cc: Kireeti Kompella; draft-kompella-l2vpn-l2vpn.all@tools.ietf.org; >> gen-art@ietf.org; IETF-Discussion list >> Subject: Re: Gen-ART LC review of draft-kompella-l2vpn-l2vpn-07 >>=20 >> Hi Roni, >>=20 >> On Sep 7, 2011, at 4:37 , Roni Even wrote: >>=20 >>> I am the assigned Gen-ART reviewer for this draft. For background on >> Gen-ART, please see the FAQ at >> . >>=20 >> Thanks! >>=20 >>> Please resolve these comments along with any other Last Call comments >> you may receive. >>>=20 >>> Document: draft-kompella-l2vpn-l2vpn-07 >>> Reviewer: Roni Even >>> Review Date: 2011-9-7 >>> IETF LC End Date: 2011-9-27 >>> IESG Telechat date: >>>=20 >>> Summary: This draft is not ready for publication as an informational >> RFC. >>>=20 >>> Major issues: >>>=20 >>> The IANA considerations section says: >>> "the values already allocated are in Table 1 of Section 4. The >> allocation policy for new entries up to and including value 127 is >> "Standards Action". The allocation policy for values 128 through 251 >> is "First Come First Served". The values from 252 through 255 are for >> "Experimental Use"." >>=20 >> Standards Action will be changed to Expert Review. >>=20 >>> Yet this is document is intended for Informational status which >> contradict the standard action. This is also true for the second >> registry defined. >>>=20 >>> Is this document really an Informational one? >>=20 >> My only comment is that it is not Historic. >>=20 >>> Minor issues: >>>=20 >>> 1. In section 1.2.2 "Since "traditional" Layer 2 VPNs (i.e., >> real Frame Relay circuits connecting sites) are indistinguishable from >> tunnel-based VPNs from the customer's point-of-view, migrating from >> one to the other raises few issues." What are the few issues? >>=20 >> A subtlety: "few issues" means not many, not deep; it's a careful way >> of saying, "just about no issues". "A few issues" would require >> elaboration. >>=20 >>> 2. In section 4 "L2VPN TLVs can be added to extend the >> information carried in the NLRI, using the format shown in Figure 2". >> How is the TLV carried in the NLRI, in which field, section 4.1 only >> talk about the structure of the TLV. >>=20 >> I'll take the figure from 3.2.2 of RFC 4761 and show where the TLVs go. >>=20 >>> 3. Section 4.2 refers to section 4 but I am not sure where this >> mechanism in section 4 is. >>=20 >> Will clarify. >>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> Nits/editorial comments: >>>=20 >>> 1. Section 3.1 is called network topology but the whole text is >> an example of a network topology. Maybe the title should be "Example of >> a network toplogy". >>=20 >> Sure. >>=20 >>> 2. Section 5 starts with "As defined so far in the document .." >> But the using IP only is already discussed in previous sections. >>=20 >> Do you have a suggestion for rewording? >>=20 >> Thanks, >> Kireeti. >>=20 >>=20 >>>=20 >>>=20 >>> >=20 From ron.even.tlv@gmail.com Fri Jan 13 09:47:16 2012 Return-Path: X-Original-To: gen-art@ietfa.amsl.com Delivered-To: gen-art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBE5B21F858D; Fri, 13 Jan 2012 09:47:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Bzg3ob42CaQ; Fri, 13 Jan 2012 09:47:16 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 712E021F8587; Fri, 13 Jan 2012 09:47:15 -0800 (PST) Received: by eaad11 with SMTP id d11so272237eaa.31 for ; Fri, 13 Jan 2012 09:47:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :content-language:thread-index; bh=LVjowe5VkJkZVX3TRCNsx9FJJNT0KPBxiSzAuj88+Wo=; b=auRTPXRvj/Y7UuiLOZWsM/wmKFzdZPDfsLkLJWy2yCvnm0O6VK3yXPuhOzaZMo2FVN y70J6COucqf00lTjy1Z2Cx0vsvPrCp47Fxe6XidymTj5tnSqyZhuZIuMYHgPLDVlO4NY Qo6z3aXnCdFQ3jzLykyrtJq1xswZ6QVr9DH20= Received: by 10.213.22.139 with SMTP id n11mr487578ebb.14.1326476834599; Fri, 13 Jan 2012 09:47:14 -0800 (PST) Received: from windows8d787f9 (bzq-79-180-198-96.red.bezeqint.net. [79.180.198.96]) by mx.google.com with ESMTPS id e12sm32130743eea.5.2012.01.13.09.47.11 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 13 Jan 2012 09:47:13 -0800 (PST) From: "Roni Even" To: "'Kireeti Kompella'" References: <4e6757ab.87c5e30a.061b.0446@mx.google.com> <4f0fdb33.c3630e0a.7550.fffff20b@mx.google.com> <3BE55A51-26E0-415F-90C5-AF1905A91237@juniper.net> In-Reply-To: <3BE55A51-26E0-415F-90C5-AF1905A91237@juniper.net> Date: Fri, 13 Jan 2012 19:43:43 +0200 Message-ID: <4f106e21.8c1b0e0a.7e1f.ffffe57a@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Content-language: en-us Thread-Index: AczSGcWVZIGwNpfQRl2KXMDU0zFrGQAAP4Yg Cc: draft-kompella-l2vpn-l2vpn.all@tools.ietf.org, gen-art@ietf.org, 'IETF-Discussion list' Subject: Re: [Gen-art] Gen-ART LC review of draft-kompella-l2vpn-l2vpn-07 X-BeenThere: gen-art@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "GEN-ART: General Area Review Team" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2012 17:47:16 -0000 Hi, I am OK with minor issue 2 now. Issue 3 was my only point Roni > -----Original Message----- > From: Kireeti Kompella [mailto:kireeti@juniper.net] > Sent: Friday, January 13, 2012 7:36 PM > To: Roni Even > Cc: Kireeti Kompella; draft-kompella-l2vpn-l2vpn.all@tools.ietf.org; > gen-art@ietf.org; IETF-Discussion list > Subject: Re: Gen-ART LC review of draft-kompella-l2vpn-l2vpn-07 > > On Jan 12, 2012, at 23:16 , Roni Even wrote: > > > Hi, > > I looked at the 08 version and the major issues are addressed. > > What about minor issue number 3? > > Good point! I will fix (as Stewart suggests, maybe just remove the > reference). > > To your minor issue (2), I've clarified the structure. Do you still > want to see how it fits into the NLRI? > > Thanks, > Kireeti. > > > Roni Even > > > >> -----Original Message----- > >> From: Kireeti Kompella [mailto:kireeti@juniper.net] > >> Sent: Friday, September 16, 2011 10:23 PM > >> To: Roni Even > >> Cc: Kireeti Kompella; draft-kompella-l2vpn-l2vpn.all@tools.ietf.org; > >> gen-art@ietf.org; IETF-Discussion list > >> Subject: Re: Gen-ART LC review of draft-kompella-l2vpn-l2vpn-07 > >> > >> Hi Roni, > >> > >> On Sep 7, 2011, at 4:37 , Roni Even wrote: > >> > >>> I am the assigned Gen-ART reviewer for this draft. For background > on > >> Gen-ART, please see the FAQ at > >> . > >> > >> Thanks! > >> > >>> Please resolve these comments along with any other Last Call > >>> comments > >> you may receive. > >>> > >>> Document: draft-kompella-l2vpn-l2vpn-07 > >>> Reviewer: Roni Even > >>> Review Date: 2011-9-7 > >>> IETF LC End Date: 2011-9-27 > >>> IESG Telechat date: > >>> > >>> Summary: This draft is not ready for publication as an > informational > >> RFC. > >>> > >>> Major issues: > >>> > >>> The IANA considerations section says: > >>> "the values already allocated are in Table 1 of Section 4. The > >> allocation policy for new entries up to and including value 127 is > >> "Standards Action". The allocation policy for values 128 through > 251 > >> is "First Come First Served". The values from 252 through 255 are > >> for "Experimental Use"." > >> > >> Standards Action will be changed to Expert Review. > >> > >>> Yet this is document is intended for Informational status which > >> contradict the standard action. This is also true for the second > >> registry defined. > >>> > >>> Is this document really an Informational one? > >> > >> My only comment is that it is not Historic. > >> > >>> Minor issues: > >>> > >>> 1. In section 1.2.2 "Since "traditional" Layer 2 VPNs (i.e., > >> real Frame Relay circuits connecting sites) are indistinguishable > >> from tunnel-based VPNs from the customer's point-of-view, migrating > >> from one to the other raises few issues." What are the few issues? > >> > >> A subtlety: "few issues" means not many, not deep; it's a careful > way > >> of saying, "just about no issues". "A few issues" would require > >> elaboration. > >> > >>> 2. In section 4 "L2VPN TLVs can be added to extend the > >> information carried in the NLRI, using the format shown in Figure > 2". > >> How is the TLV carried in the NLRI, in which field, section 4.1 only > >> talk about the structure of the TLV. > >> > >> I'll take the figure from 3.2.2 of RFC 4761 and show where the TLVs > go. > >> > >>> 3. Section 4.2 refers to section 4 but I am not sure where > this > >> mechanism in section 4 is. > >> > >> Will clarify. > >> > >>> > >>> > >>> > >>> > >>> > >>> Nits/editorial comments: > >>> > >>> 1. Section 3.1 is called network topology but the whole text > is > >> an example of a network topology. Maybe the title should be "Example > >> of a network toplogy". > >> > >> Sure. > >> > >>> 2. Section 5 starts with "As defined so far in the document > .." > >> But the using IP only is already discussed in previous sections. > >> > >> Do you have a suggestion for rewording? > >> > >> Thanks, > >> Kireeti. > >> > >> > >>> > >>> > >>> > > From ben@nostrum.com Fri Jan 13 14:00:10 2012 Return-Path: X-Original-To: gen-art@ietfa.amsl.com Delivered-To: gen-art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5879511E8081; Fri, 13 Jan 2012 14:00:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.368 X-Spam-Level: X-Spam-Status: No, score=-102.368 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uji+hLsNOd3d; Fri, 13 Jan 2012 14:00:09 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id A0FE611E8072; Fri, 13 Jan 2012 14:00:09 -0800 (PST) Received: from dn3-53.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q0DM08Lh064149 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 13 Jan 2012 16:00:09 -0600 (CST) (envelope-from ben@nostrum.com) From: Ben Campbell Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Date: Fri, 13 Jan 2012 16:00:08 -0600 Message-Id: <5FBCE42B-679F-4BD5-B30B-A11664734A0B@nostrum.com> To: draft-ietf-kitten-sasl-saml.all@tools.ietf.org Mime-Version: 1.0 (Apple Message framework v1251.1) X-Mailer: Apple Mail (2.1251.1) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: "gen-art@ietf.org Review Team" , The IETF Subject: [Gen-art] Gen-ART Telechat Review of draft-ietf-kitten-sasl-saml-08 X-BeenThere: gen-art@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "GEN-ART: General Area Review Team" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2012 22:00:10 -0000 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-kitten-sasl-saml-08 Reviewer: Ben Campbell Review Date: 2012-01-13 IESG Telechat date: 2012-01-19 Summary: This draft is almost ready for publication as a proposed = standard. There are a few minor issues that should be considered first. Note: This is incremental to my review of version 06 at last call. = Version 08 is considerably improved and resolved most of my comments. = But a few still remain. Quoted text below is from that previous review. Major issues: None Minor issues: > -- section 3.2, last paragraph: "=85 needs to correlate the TCP = session from the SASL client with the SAML authentication." >=20 > Please elaborate on this correlation The author added text, but the new text is about correlating response = with request. The text I mentioned was about correlating a TCP = connection to a SAML authentication. > -- section 4, 3rd and 4th paragraph (paragraph a and b) >=20 > These seem like protocol affecting differences. If so, they need = elaboration, such as normative statements and formal definitions, or = references to such. I did not see a response to this comment. > -- section 5, general: >=20 > The section seems to need further elaboration or references I did not see a response to this comment. > Also, this section compresses the interaction with the identity = provider. Why not show the details for those steps like the others? (If = you mean them to be out of scope, then why give as much detail as you = do?) >=20 I did not see a response to this comment. Nits/editorial comments: > -- Pagination is strange throughout the document. (Mostly blank pages, = etc.) It's worse in the PDF version, but still not right in the text = version. Pagination is still strange. I see a few mostly blank pages, diagrams = split across page breaks, etc. > -- section 3, 1st paragraph: "Recall section 5 of [RFC4422] for what = needs to be described here." >=20 > That reads like an author's "to do" note to himself. Has the needed = description been completed, or does it still need to be described? Partially fixed. I suggest s/"needs to be"/"is" > -- section 3.1, first paragraph: >=20 > Is "authorization identifier" the same as "IdP-Identifier"? The paragraph has been updated, but I still have the question.=20 > -- section 3.3, 2nd paragraph: "and SHALL be used to set state in the = server accordingly, and it shall be used by the server" >=20 > Is this new normative language, or a repeat of language from the SAML = spec? >=20 The author changed SHALL to MUST, which leads me to believe my comment = was not clear. I did not object to SHALL. My concern was, with the = reference to RFC4422, it was not clear if the text was introduction a = new normative requirement, or just restating requirements from 4422. If = the second, then it's important to make sure the reader knows which doc = is authoritative. You can do that by keeping the language descriptive, = or by explicitly (and strongly) attributing the language with something = like 'RFC4433 says, "=85. SHALL=85."' If, on the other hand, this is truly a new normative statement, then no = change is needed. > -- section 4, 1st paragraph: >=20 > I have difficulty parsing this. The text is updated, but I still have trouble parsing it. In particular, = I'm not sure what you mean by the phrase "...and appropriate references = of it not referenced elsewhere in this document=85". > -- section 7=20 >=20 > Does the GSS-API description introduce security considerations? If = not, please say so. >=20 I did not see a response to this comment. From ietfdbh@comcast.net Fri Jan 13 15:30:08 2012 Return-Path: X-Original-To: gen-art@ietfa.amsl.com Delivered-To: gen-art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26AF121F84D3 for ; Fri, 13 Jan 2012 15:30:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.425 X-Spam-Level: X-Spam-Status: No, score=-102.425 tagged_above=-999 required=5 tests=[AWL=0.174, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8-Br6TSf5C4a for ; Fri, 13 Jan 2012 15:30:07 -0800 (PST) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [76.96.62.40]) by ietfa.amsl.com (Postfix) with ESMTP id 0678A21F84CD for ; Fri, 13 Jan 2012 15:30:06 -0800 (PST) Received: from omta16.westchester.pa.mail.comcast.net ([76.96.62.88]) by qmta04.westchester.pa.mail.comcast.net with comcast id M02s1i0041uE5Es54BW7ud; Fri, 13 Jan 2012 23:30:07 +0000 Received: from davidPC ([71.233.85.150]) by omta16.westchester.pa.mail.comcast.net with comcast id MBW61i00R3Ecudz3cBW6Hd; Fri, 13 Jan 2012 23:30:07 +0000 From: "David Harrington" To: "'Tom Taylor'"