[Gen-art] Gen-ART LC review of draft-ietf-opsec-protect-control-plane-04

[Roni Even]

Hi,

 

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-opsec-protect-control-plane-04

 

Reviewer: Roni Even

Review Date: 2010-11-28

IETF LC End Date: 2010-12-3

IESG Telechat date: (if known)

 

Summary: This draft is ready for publication as an Informational RFC. There
are some nits and minor issue.

 

Major issues:

 

Minor issues: The example in appendix A are using syntax with no reference.
The text says that this is non normative text but I think that it will be
good to have a reference to the document where the correct syntax is
specified

 

Nits/editorial comments:

 

1.  The first sentence of section 1 "Modern router architecture design
maintains a strict separation of forwarding and routing control plane
hardware and software." Talks about routing control plane while the next
sentence and the rest of the document calls it "router control plane"

2.  In section 2 third paragraph "Additionally, there may be other
vendor or implementation specific protection mechanisms that are on by
default or always on. ". I suggest changing the text "are on" and "always
on" maybe to "active" or "turned on".

 

Thanks

Roni Even

 

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART LC review of draft-ietf-opsec-protect-control-plane-04

[Joel Jaeggli]

Active is fine, turned on And always on have different meanings however. 

I think we can fix appendix a with the appropriate informative reference as 
specified.

Joel's widget number 2

On Nov 28, 2010, at 7:39, "Roni Even"  wrote:

> Hi,
> 
>  
> 
> 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-opsec-protect-control-plane-04
> 
>  
> 
> Reviewer: Roni Even
> 
> Review Date: 2010-11-28
> 
> IETF LC End Date: 2010-12-3
> 
> IESG Telechat date: (if known)
> 
>  
> 
> Summary: This draft is ready for publication as an Informational RFC. There 
> are some nits and minor issue.
> 
>  
> 
> Major issues:
> 
>  
> 
> Minor issues: The example in appendix A are using syntax with no reference. 
> The text says that this is non normative text but I think that it will be 
> good to have a reference to the document where the correct syntax is specified
> 
>  
> 
> Nits/editorial comments:
> 
>  
> 
> 1.  The first sentence of section 1 "Modern router architecture design 
> maintains a strict separation of forwarding and routing control plane 
> hardware and software." Talks about routing control plane while the next 
> sentence and the rest of the document calls it "router control plane"
> 
> 2.  In section 2 third paragraph "Additionally, there may be other vendor 
> or implementation specific protection mechanisms that are on by default or 
> always on. ". I suggest changing the text "are on" and "always on" maybe to 
> "active" or "turned on".
> 
>  
> 
> Thanks
> 
> Roni Even
> 
>  
> 
> ___
> Ietf mailing list
> i...@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART LC review of draft-ietf-opsec-protect-control-plane-04

[Roni Even]

Rodney,
What I meant and I think Joel got it right is to add informative reference to 
the manuals/documents where you can see how to write policy similar to the ones 
in the appendix.
BTW: You can make all changes after the IETF LC is finished (December 3rd)

Roni

> -Original Message-
> From: Rodney Dunn [mailto:rod...@cisco.com]
> Sent: Sunday, November 28, 2010 6:09 PM
> To: Joel Jaeggli
> Cc: Roni Even; General Area Review Team; IETF-Discussion list; draft-
> ietf-opsec-protect-control-plane@tools.ietf.org
> Subject: Re: Gen-ART LC review of draft-ietf-opsec-protect-control-
> plane-04
> 
> Joel,
> 
> I had responded offline to Roni to get clarification on the reference
> part. I wasn't clear as to what what the informative reference should
> be.
> 
> Here was my response:
> 
> "rd> The idea was that the text in the draft is normative but the
> configuration examples are not as they are many different ways for the
> configurations to be constructed to accomplish the same output. While
> some are more optimized from a number of lines perspective they didn't
> map clearly enough between the two examples or as clearly illustrate
> the
> example logic.
> 
> I'm not sure what you meant by "where the correct syntax is specified".
> The syntax used is correct just there are various ways it can be
> configured. Some actually come down to personal preference so there is
> no "correct" in the sense of implementation uniqueness."
> 
> Can you clarify it for me?
> 
> I updated the other two points and went with "active" on the second.
> 
> Thanks,
> Rodney
> 
> 
> 
> 
> On 11/28/10 11:05 AM, Joel Jaeggli wrote:
> > Active is fine, turned on And always on have different meanings
> however.
> >
> > I think we can fix appendix a with the appropriate informative
> reference
> > as specified.
> >
> > Joel's widget number 2
> >
> > On Nov 28, 2010, at 7:39, "Roni Even"  > > wrote:
> >
> >> Hi,
> >>
> >> I am the assigned Gen-ART reviewer for this draft. For background on
> >> Gen-ART, please see the FAQ at
> >>
> <http://wiki.t
> ools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
> >>
> >> Please resolve these comments along with any other Last Call
> comments
> >> you may receive.
> >>
> >> Document: draft-ietf-opsec-protect-control-plane-04
> >>
> >> Reviewer: Roni Even
> >>
> >> Review Date: 2010-11-28
> >>
> >> IETF LC End Date: 2010-12-3
> >>
> >> IESG Telechat date: (if known)
> >>
> >> Summary: This draft is ready for publication as an Informational
> RFC.
> >> There are some nits and minor issue.
> >>
> >> Major issues:
> >>
> >> Minor issues: The example in appendix A are using syntax with no
> >> reference. The text says that this is non normative text but I think
> >> that it will be good to have a reference to the document where the
> >> correct syntax is specified
> >>
> >> Nits/editorial comments:
> >>
> >> 1.The first sentence of section 1 "Modern router architecture design
> >> maintains a strict separation of forwarding and routing control
> plane
> >> hardware and software." Talks about routing control plane while the
> >> next sentence and the rest of the document calls it "router control
> plane"
> >>
> >> 2.In section 2 third paragraph "Additionally, there may be other
> >> vendor or implementation specific protection mechanisms that are on
> by
> >> default or always on. ". I suggest changing the text "are on" and
> >> "always on" maybe to "active" or "turned on".
> >>
> >> Thanks
> >>
> >> Roni Even
> >>
> >> ___
> >> Ietf mailing list
> >> i...@ietf.org 
> >> https://www.ietf.org/mailman/listinfo/ietf

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART LC review of draft-ietf-opsec-protect-control-plane-04

[Rodney Dunn]

Joel,

I had responded offline to Roni to get clarification on the reference 
part. I wasn't clear as to what what the informative reference should be.


Here was my response:

"rd> The idea was that the text in the draft is normative but the 
configuration examples are not as they are many different ways for the 
configurations to be constructed to accomplish the same output. While 
some are more optimized from a number of lines perspective they didn't 
map clearly enough between the two examples or as clearly illustrate the 
example logic.


I'm not sure what you meant by "where the correct syntax is specified". 
The syntax used is correct just there are various ways it can be 
configured. Some actually come down to personal preference so there is 
no "correct" in the sense of implementation uniqueness."


Can you clarify it for me?

I updated the other two points and went with "active" on the second.

Thanks,
Rodney




On 11/28/10 11:05 AM, Joel Jaeggli wrote:

Active is fine, turned on And always on have different meanings however.

I think we can fix appendix a with the appropriate informative reference
as specified.

Joel's widget number 2

On Nov 28, 2010, at 7:39, "Roni Even" mailto:ron.even@gmail.com>> wrote:


Hi,

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 resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-opsec-protect-control-plane-04

Reviewer: Roni Even

Review Date: 2010-11-28

IETF LC End Date: 2010-12-3

IESG Telechat date: (if known)

Summary: This draft is ready for publication as an Informational RFC.
There are some nits and minor issue.

Major issues:

Minor issues: The example in appendix A are using syntax with no
reference. The text says that this is non normative text but I think
that it will be good to have a reference to the document where the
correct syntax is specified

Nits/editorial comments:

1.The first sentence of section 1 "Modern router architecture design
maintains a strict separation of forwarding and routing control plane
hardware and software." Talks about routing control plane while the
next sentence and the rest of the document calls it "router control plane"

2.In section 2 third paragraph "Additionally, there may be other
vendor or implementation specific protection mechanisms that are on by
default or always on. ". I suggest changing the text "are on" and
"always on" maybe to "active" or "turned on".

Thanks

Roni Even

___
Ietf mailing list
i...@ietf.org 
https://www.ietf.org/mailman/listinfo/ietf

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART LC review of draft-ietf-opsec-protect-control-plane-04

[Rodney Dunn]

Got it. Thanks.

We (the authors) will talk it over and figure out the best location to 
reference to cover that and how.


Again, thanks for the review. Point noted on the LC date.

Rodney



On 11/28/10 11:43 AM, Roni Even wrote:

Rodney,
What I meant and I think Joel got it right is to add informative reference to 
the manuals/documents where you can see how to write policy similar to the ones 
in the appendix.
BTW: You can make all changes after the IETF LC is finished (December 3rd)

Roni


-Original Message-
From: Rodney Dunn [mailto:rod...@cisco.com]
Sent: Sunday, November 28, 2010 6:09 PM
To: Joel Jaeggli
Cc: Roni Even; General Area Review Team; IETF-Discussion list; draft-
ietf-opsec-protect-control-plane@tools.ietf.org
Subject: Re: Gen-ART LC review of draft-ietf-opsec-protect-control-
plane-04

Joel,

I had responded offline to Roni to get clarification on the reference
part. I wasn't clear as to what what the informative reference should
be.

Here was my response:

"rd>  The idea was that the text in the draft is normative but the
configuration examples are not as they are many different ways for the
configurations to be constructed to accomplish the same output. While
some are more optimized from a number of lines perspective they didn't
map clearly enough between the two examples or as clearly illustrate
the
example logic.

I'm not sure what you meant by "where the correct syntax is specified".
The syntax used is correct just there are various ways it can be
configured. Some actually come down to personal preference so there is
no "correct" in the sense of implementation uniqueness."

Can you clarify it for me?

I updated the other two points and went with "active" on the second.

Thanks,
Rodney




On 11/28/10 11:05 AM, Joel Jaeggli wrote:

Active is fine, turned on And always on have different meanings

however.


I think we can fix appendix a with the appropriate informative

reference

as specified.

Joel's widget number 2

On Nov 28, 2010, at 7:39, "Roni Even"mailto:ron.even@gmail.com>>  wrote:


Hi,

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at


<http://wiki.t
ools.ietf.org/area/gen/trac/wiki/GenArtfaq>.


Please resolve these comments along with any other Last Call

comments

you may receive.

Document: draft-ietf-opsec-protect-control-plane-04

Reviewer: Roni Even

Review Date: 2010-11-28

IETF LC End Date: 2010-12-3

IESG Telechat date: (if known)

Summary: This draft is ready for publication as an Informational

RFC.

There are some nits and minor issue.

Major issues:

Minor issues: The example in appendix A are using syntax with no
reference. The text says that this is non normative text but I think
that it will be good to have a reference to the document where the
correct syntax is specified

Nits/editorial comments:

1.The first sentence of section 1 "Modern router architecture design
maintains a strict separation of forwarding and routing control

plane

hardware and software." Talks about routing control plane while the
next sentence and the rest of the document calls it "router control

plane"


2.In section 2 third paragraph "Additionally, there may be other
vendor or implementation specific protection mechanisms that are on

by

default or always on. ". I suggest changing the text "are on" and
"always on" maybe to "active" or "turned on".

Thanks

Roni Even

___
Ietf mailing list
i...@ietf.org
https://www.ietf.org/mailman/listinfo/ietf



___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] ***SPAM*** 5.833 (5) Gen-art LC review of draft-ietf-sipcore-reinvite-07.txt

[Elwyn Davies]

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-sipcore-reinvite-07
Reviewer: Elwyn Davies
Review Date: 2010-10-19
IESG Telechat date: 2010-12-02

Summary:
Ready.  The couple of nits I identfied are fixed.



___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Gen-ART LC review of draft-ietf-httpstate-cookie-18

[Richard L. Barnes]

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-httpstate-cookie-18
Reviewer: Richard Barnes
Review Date: 28 November 2010
IETF LC End Date: 2 December 2010
IESG Telechat date: (unknown)

Summary: This document is close to being ready for publication, but could 
benefit from several clarifications and upgrades to requirements language.  In 
particular, user agent security requirements need to be slightly stronger.


Major issues:

[S8.6] Many of these integrity issues are caused by user agents accepting 
cookies from outside the context where they would send them, in particular with 
the Secure and Path attributes.  It seems like this document, in specifying the 
desired/proper behavior of user agents, should require behavior that would 
mitigate these attacks.  In direct parallel to the handling of the Domain 
attribute:
1. Set-Cookies with the Secure flag should only be accepted over secure channels
2. Set-Cookies with the Path attribute set should only be accepted if the path 
value matches the request-uri of the request
(That is, update Steps 7 and 8 of S5.3 to match Steps 6 and 9/10) I realize 
that as long as there are legacy user agents out there, servers can't rely on 
these protections, but if any user agents implement these requirements, then 
fewer transactions will be subject to these attacks.


Minor issues:

[General] It would be very helpful if this document had a summary of changes 
from RFC 2965, and possibly from RFC 2109 as well.  In particular, the fate of 
the Cookie2 and Set-Cookie2 header fields is a little unclear.  If the intent 
of obsoleting 2965 is to deprecate the use of these fields, it would be good to 
state that explicitly.

[General] It's unclear where this document fits on the scale of "documenting 
existing behavior" to "describing proper behavior".  It seems like the focus 
should be on documenting a proper behavior that is maximally compatible with 
existing behavior.  The document should try to clearly distinguish when it is 
talking about the desired behavior vs. the existing behavior.  The former 
should be subject to strong requirements "MUSTs" while the latter will have no 
requirements at all.

[S2.3 P2] Is the request-host the same as the value of the HTTP/1.1 Host header 
field?

[S3 P4] It seems like there should be an all-caps requirement here, e.g., that 
"Origin servers MUST NOT fold multiple Set-Cookie header fields into a single 
header field". 

[S4.1.1 P1] It seems like it should be MUST NOT instead of SHOULD NOT: "Servers 
MUST NOT send Set-Cookie headers that fail to conform to the following 
grammar:".

[S4.1.1] Is there a reason that path-value is so unconstrained?  Based on 
S5.1.4, I would have expected it to be abs_path (from RFC 2396).

[S4.1.1 P5] Seems like the SHOULD NOT should be "MUST NOT produce more than one 
attribute with the same name".

[S4.1.1 P6] Either this should be a "MUST NOT" or it should define which a user 
agent MUST accept -- or both.  The third paragraph of 4.1.2 seems to imply that 
the user agent MUST accept the last one (in order of appearance in the HTTP 
header).

[S4.1.1 P8] Again, "SHOULD" -> "MUST"

[S8.1] I find this paragraph vague and confusing.  I would suggest separating 
protocol vulnerabilities from implementation vulnerabilities.  Suggested text:
"
Transport-layer encryption, such as that employed in HTTPS, is insufficient to 
prevent a network attacker from obtaining or altering a victim's cookies.  The 
cookie protocol itself allows cookies to be accessed or modified from other 
contexts (subdomains, subordinate paths, or other ports) and some user agents 
do not even provide the separations required by the protocol.  (See "Weak 
Confidentiality" and "Weak Integrity", below).  
"


Nits/editorial comments:

[S2.1 P3 "not intended to be performant"] I'm not sure the word "performant" 
has the meaning that seems to be intended here.  (The definitions I'm finding 
indicate "one who performs".)  Should probably expand to "not intended to 
require the performance of specific steps". 

[S3 P2 "the default scope"] The notion of the "scope" of a cookie was only 
briefly introduced in the Introduction.  Could be good to remind the reader in 
the first paragraph.  "... the user agent will return in future HTTP requests." 
-> "... the user will return in future HTTP requests that are within the scope 
of the cookie".

[S4.1.1 P9] The paragraph as it stands is kind of useless -- what am I supposed 
to do with this information?  Suggest changing to:
"
Some user agents represent dates using 32-bit UNIX time_t values.  These user 
agents will process dates after January 19, 2038 incorrectly.  Origin servers 
SHOULD NOT set expiration times later than this time. 
"

[S4.1.2] The phrase "Non-Normative" 

Re: [Gen-art] Assignments for Dec 2, 2010 Telechat

[Russ Housley]

Does it mean that no reviewer is assigned for these two documents?

Russ


draft-ietf-xmpp-3920bis [txt]
Extensible Messaging and Presence Protocol (XMPP): Core (Proposed Standard)
Note: Ben Campbell (b...@nostrum.com) is the document shepherd.
Token: Gonzalo Camarillo (rai area)
Reviewer:


draft-ietf-xmpp-address [txt]
Extensible Messaging and Presence Protocol (XMPP): Address Format
(Proposed Standard)
Note: Ben Campbell (b...@nostrum.com) is the document shepherd.
Token: Gonzalo Camarillo (rai area)
Reviewer:



On 11/27/2010 3:39 PM, Mary Barnes wrote:
> Hi all,
> 
> Apologies yet again for the delay. 
> 
> Here's the link to the summary of assignments for the Dec 2nd, 2010
> telechat:
> http://www.softarmor.com/rai/temp-gen-art/reviewers-101202.html
> 
> With the updated spreadsheets:
> http://www.softarmor.com/rai/temp-gen-art/gen-art.html
> http://www.softarmor.com/rai/temp-gen-art/gen-art-by-reviewer.html
> 
> 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/
> 
> Mary.
> 
> ---
> 
> 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:
> 
> 
> 
> ___
> Gen-art mailing list
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] A *new* batch of IETF LC reviews - 25 Nov 2010

[Mary Barnes]

I have no idea why the link goes to the 101118 file - either gmail or safari
goofiness.  Here's the correct link (maybe):
http://www.softarmor.com/rai/temp-gen-art/reviewers-101125-lc.html

Mary.

On Sat, Nov 27, 2010 at 2:42 PM, Mary Barnes wrote:

> Hi all,
>
> Please note that the ADs have gone wild with LCs over the past week and I
> am a bit late in getting some of the ones the week before assigned, so there
> are a few that are coming up quickly.
>
> Here's the link to the new LC assignments for last week:
> http://www.softarmor.com/rai/temp-gen-art/reviewers-101125-lc.html
>
> The assignments are captured in the spreadsheets:
> http://www.softarmor.com/rai/temp-gen-art/gen-art.html
> http://www.softarmor.com/rai/temp-gen-art/gen-art-by-reviewer.html
>
> The standard template is included below.
>
> Thanks,
> Mary.
> ---
>
> 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 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

Re: [Gen-art] Assignments for Dec 2, 2010 Telechat

[Elwyn Davies]

Gosh I am a sucker for punishment!

I'll have a go at xmpp-3920bis - only 205 pages or something.
I'll try my level best to have the review done by the time time Russ
wakes up on Tuesday, but it might stretch out until Wednesday.

Regards,
Elwyn

On Sun, 2010-11-28 at 15:49 -0500, Russ Housley wrote:
> Does it mean that no reviewer is assigned for these two documents?
> 
> Russ
> 
> 
> draft-ietf-xmpp-3920bis [txt]
> Extensible Messaging and Presence Protocol (XMPP): Core (Proposed Standard)
> Note: Ben Campbell (b...@nostrum.com) is the document shepherd.
> Token: Gonzalo Camarillo (rai area)
> Reviewer:
> 
> 
> draft-ietf-xmpp-address [txt]
> Extensible Messaging and Presence Protocol (XMPP): Address Format
> (Proposed Standard)
> Note: Ben Campbell (b...@nostrum.com) is the document shepherd.
> Token: Gonzalo Camarillo (rai area)
> Reviewer:
> 
> 
> 
> On 11/27/2010 3:39 PM, Mary Barnes wrote:
> > Hi all,
> > 
> > Apologies yet again for the delay. 
> > 
> > Here's the link to the summary of assignments for the Dec 2nd, 2010
> > telechat:
> > http://www.softarmor.com/rai/temp-gen-art/reviewers-101202.html
> > 
> > With the updated spreadsheets:
> > http://www.softarmor.com/rai/temp-gen-art/gen-art.html
> > http://www.softarmor.com/rai/temp-gen-art/gen-art-by-reviewer.html
> > 
> > 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/
> > 
> > Mary.
> > 
> > ---
> > 
> > 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:
> > 
> > 
> > 
> > ___
> > Gen-art mailing list
> > Gen-art@ietf.org
> > https://www.ietf.org/mailman/listinfo/gen-art
> ___
> Gen-art mailing list
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART last call review of draft-ietf-emu-eaptunnel-req-08

[Joe Salowey]

Hi Roni,

Sorry I missed your first message, thank you for resending it.Comments in 
line below:

Cheers,

Joe

On Nov 27, 2010, at 11:34 PM, Roni Even wrote:

> Hi,
> I sent the following review on October 25th but did not see and response.
>  
> Roni Even
>  
>  
>  
> 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-emu-eaptunnel-req-08
> Reviewer: Roni Even
> Review Date:2010–10–25
> IETF LC End Date: 2010–11–10
> IESG Telechat date:2010-12-2
>  
> Summary: This draft is almost ready for publication as an Informational RFC.
>  
> Major issues:
>  
> Minor issues:
> 1.   In section 2  why not reference RFC 2119 or at least  copy the 
> definition from RFC 2119 for  the capitalized term.
> 

[Joe] We followed the convention used in RFC 5209 (NEA protocol requirements), 
because this document is defining requirements rather than the protocol itself. 
 

> 2.   In section 3.9 when you say “if this technique is used”, by this do 
> you mean certificate –less or the flow defined in the previous sentence.
> 


[Joe] "if this technique is used" refers to certificatel-less authentication 
using the inner EAP method for client authentication without server 
authentication.   Perhaps the following sentence would be clearer:

"If an inner EAP method is used for client authentication without full server 
validation the inner method MUST provide
   resistance to dictionary attack and a cryptographic binding between the 
inner method and the tunnel method MUST be established. ..."

Does this help? 

> 3.   In section 4.6.3 the first paragraph defines the requirements for 
> Cryptographic Binding. It looks to me like the rest of the section talks 
> about a specific use case, so why is it in the requirements section and not 
> in section 3.
> 
[Joe]  The majority of section 4.6.3 discusses a possible mechanism to achieve 
cryptographic binding.  While it is not specifically a requirement I think it 
supports the requirement defined in the first paragraph.  I do not think it 
belongs in the use case section.  


>  
>  
>  
> Nits/editorial comments:
>  
> ___
> Ietf mailing list
> i...@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art