[Gen-art] Assignments for April 22, 2010 Telechat

[Mary Barnes]

Hi all,

Here's the link to the summary of assignments for the April 22, 2010 telechat:
http://www.softarmor.com/rai/temp-gen-art/reviewers-100422.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://www.alvestrand.no/ietf/gen/art/review-guidelines.html

Mary.

---

I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document:
Reviewer:
Review Date:
IESG Telechat date: 22 April 2010

Summary:

Major issues:
Minor issues:
Nits/editorial comments:
 Reply
 Forward
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] A *new* batch of IETF LC reviews - 15 April 2010

[Mary Barnes]

Hi all,

Here's the link to the new LC assignments for this week:
http://www.softarmor.com/rai/temp-gen-art/reviewers-100415-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 have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

Please 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

[Gen-art] Gen-ART review of draft-altman-tls-channel-bindings-12.txt

[Suresh Krishnan]

I am the assigned Gen-ART reviewer for
draft-altman-tls-channel-bindings-12.txt

For background on Gen-ART, please see the FAQ at
.

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

Summary: This draft is almost ready for publication as Proposed Standard 
but please consider my comments on -07 (especially the wrong reference).


* Section 2

"Subsequent to the publication of "On Channel Bindings" [RFC5246]"

Shouldn't this reference point to RFC5056 instead?

* Normative references

Why are the normative references for 'tls-server-end-point' separated
out from the other normative references?

Thanks
Suresh












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

Re: [Gen-art] Gen-ART review of draft-altman-tls-channel-bindings-12.txt

[Nicolas Williams]

On Fri, Apr 16, 2010 at 01:26:09PM -0400, Suresh Krishnan wrote:
> I am the assigned Gen-ART reviewer for
> draft-altman-tls-channel-bindings-12.txt
> 
> For background on Gen-ART, please see the FAQ at
> .
> 
> Please resolve these comments along with any other Last Call comments
> you may receive.
> 
> Summary: This draft is almost ready for publication as Proposed
> Standard but please consider my comments on -07 (especially the
> wrong reference).
> 
> * Section 2
> 
> "Subsequent to the publication of "On Channel Bindings" [RFC5246]"
> 
> Shouldn't this reference point to RFC5056 instead?

Yes.  I keep forgetting to fix that :(

> * Normative references
> 
> Why are the normative references for 'tls-server-end-point' separated
> out from the other normative references?

That's to clarify that FIPS-180-2 is not something that tls-unique
depends on.  (Actually, this section should be named "Additional
Normative References for 'tls-server-end-point'".)

This clarification is, strictly speaking, not necessary.  But it also
does no harm.  If the RFC-Editor objects we'll fold it into the
normative references section.

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

Re: [Gen-art] Gen-ART review of draft-altman-tls-channel-bindings-12.txt

[Nicolas Williams]

PS: Thanks for your review!
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Gen-ART Telechat review of draft-ietf-netmod-yang-types-08

[Ben Campbell]

I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-ietf-netmod-yang-types-08
Reviewer: Ben Campbell
Review Date: 16 April 2010
IESG Telechat date: 22 April 2010

Summary: Ready for publication as a proposed standard

Major issues: None
Minor issues: None
Nits/editorial comments: None


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

Re: [Gen-art] Gen-ART (belated) LC Review of draft-ietf-nsis-nslp-natfw-23

[Ben Campbell]

Hi, thanks for the response. Comments inline. I removed sections for issues 
that I think are closed:

On Apr 9, 2010, at 6:53 AM, Martin Stiemerling wrote:

[...]

>> 
>> -- section 3.2.8, "transitory" bullet: "When a node has received a
>> NOTIFY message, it
>>  marks the signaling session as 'transitory'."
>> 
>> I assume this is content dependent, right? That is, this is not true
>> for any arbitrary NOTIFY?
> 
> It is transitory for any NOTIFY.
> 
> NOTIFY is indicating that something did get wrong along the path and
> that the NI should react immediately to this. However, making it
> context dependent has the risk that, if the path back to the NI is
> broken or if the path from the NI to the NFs is broken, that NFs will
> keep state for a too long time (probably until the session expires -
> which might be long time), despite the fact that the state is not
> needed anymore. 
> 

Okay.

[...]

> 
>> 
>> -- section 3.4, 4th bullet:
>> 
>> I'm not sure what "data exchange duration" means. Is this the time over
>> which the DS expects to send exchange data with the DR, or is it the
>> time required for one round-trip data exchange? If the first, how is
>> the DS expected to know this in advance?
> 
> It is the time over which DS is sending its data. The formulation is bit
> blurry, as neither of us can tell how long this time will actually be.
> The time can range from few minutes (ftp download) to days (if used with
> GRID stuff). The way how the DS learns this is up to the implementer.
> 

Okay.



>> 
>> -- section 3.4, paragraph before numbered list:
>> 
>> Should there be a normative statement about using this algorithm?
>> (MAY/MUST/SHOULD)?
> 
> I would say it should read RECOMMENDED. Is that fine?
> 

Works for me.

>> 
>> -- section 3.4, first paragraph after numbered list:
>> 
>> Is "refresh timer" the same thing as "message refresh period"? (i.e.
>> "R", above?)
> 
> No, see text in 3.4:
> "   1.  The refresh message timer to be randomly set to a value in the
>  range [0.5R, 1.5R]."
> 
> " This duration is modeled as R, with R the  message refresh period (in 
> seconds);"
> 

Okay,


>> 
>> -- section 3.4, paragraphs about signalling session lifetime being too
>> big or small
>> 
>> Does the RESPONSE carry hints about the largest or smallest allowed
>> value?
> 
> No it does not. However, there is no indication what the appropriate range is.
> How about adding the NATFW lifetime object to that error response message, in
> which the maximum session lifetime is indicated?
> 

Works for me. Are you proposing a change to the text? ( I don't see this in 
version 24)

[...]


>> 
>> -- section 3.7.1, "Firewall:" sub-bullet:
>> 
>> When is "later on"?
>> 
>> If the FW gets a success RESPONSE from downstream, generates an error
>> RESPONSE due to a local failure, how do downstream devices learn of
>> this? Does it need to send a NOTIFY towards the NR?
> 
> This is a mistake in the text - I guess this text got missed while
> editing. 
> 
> Changed to text to address the fact that error must be generated at the
> time when the CREATE is received, as the policy rule is already reserved
> and all checks whether it is compliant with local policies has to be
> done at that time. 
> 
> OLD:
> When the initial CREATE message is received at
> the private side, the NAT binding is allocated, but not
> activated (see also Appendix D.3).  An error RESPONSE message
> is generated, if the requested policy rule cannot be installed
> later on, of class 'Signaling session failure' (0x6) with
> response code 'Requested policy rule denied due to policy
> conflict' (0x4).  The MRI information is updated to reflect the
> 
> NEW:
> When the initial CREATE message is received at
> the private side, the NAT binding is allocated, but not
> activated (see also Appendix D.3).  An error RESPONSE message
> is generated, if the requested policy rule cannot be reserved
> right away, of class 'Signaling session failure' (0x6) with
> response code 'Requested policy rule denied due to policy
> conflict' (0x4).  The MRI information is updated to reflect the
> 

I think the change is good, but I notice you applied it to the NAT bullet, and 
my comment was on the Firewall bullet. I suspect the same issue applies to both?


[...]

> 
>> 
>> 2nd and 3rd sentence do not parse.
> 
> OLD
>   Each network edge that has the NATFW NSLP deployed can use EXTERNAL
>   request message to allow a secure access to the network.  This will
>   allow to open the firewall/NAT on the receiver's side.  However, the
>   edge-devices should not allow to be opened up completely, but to let
>   DR's to reserve very specific policies.  For instance, a DR can
>   request to reserve an 'allow' policy rule for an incoming TCP
> 
> NEW:
>   Each network edge that has the NATFW NSLP deployed can use the
>   EXTERNAL request message to allow a secure 

[Gen-art] Gen-ART Telechat Review of draft-ietf-nsis-nslp-natfw-24

[Ben Campbell]

I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-ietf-nsis-nslp-natfw-24
Reviewer: Ben Campbell
Review Date: 16 April 2010
IESG Telechat date: 22 April 2010

Summary: Ready for publication as an experimental RFC. I have a couple of very 
minor editorial comments remaining from my last call review that you may 
consider, but probably shouldn't block anything.

Major issues: None

Minor issues: None

Nits/editorial comments:

-- a couple of editorial comments/questions copied from the email conversation 
on the subject:

>>> 
>>> 
>>> -- section 3.4, paragraphs about signalling session lifetime being too
>>> big or small
>>> 
>>> Does the RESPONSE carry hints about the largest or smallest allowed
>>> value?
>> 
>> No it does not. However, there is no indication what the appropriate range 
>> is.
>> How about adding the NATFW lifetime object to that error response message, in
>> which the maximum session lifetime is indicated?
>> 
> 
> Works for me. Are you proposing a change to the text? ( I don't see this in 
> version 24)

[...]

>>> 
>>> -- section 3.7.1, "Firewall:" sub-bullet:
>>> 
>>> When is "later on"?
>>> 
>>> If the FW gets a success RESPONSE from downstream, generates an error
>>> RESPONSE due to a local failure, how do downstream devices learn of
>>> this? Does it need to send a NOTIFY towards the NR?
>> 
>> This is a mistake in the text - I guess this text got missed while
>> editing. 
>> 
>> Changed to text to address the fact that error must be generated at the
>> time when the CREATE is received, as the policy rule is already reserved
>> and all checks whether it is compliant with local policies has to be
>> done at that time. 
>> 
>> OLD:
>>When the initial CREATE message is received at
>>the private side, the NAT binding is allocated, but not
>>activated (see also Appendix D.3).  An error RESPONSE message
>>is generated, if the requested policy rule cannot be installed
>>later on, of class 'Signaling session failure' (0x6) with
>>response code 'Requested policy rule denied due to policy
>>conflict' (0x4).  The MRI information is updated to reflect the
>> 
>> NEW:
>>When the initial CREATE message is received at
>>the private side, the NAT binding is allocated, but not
>>activated (see also Appendix D.3).  An error RESPONSE message
>>is generated, if the requested policy rule cannot be reserved
>>right away, of class 'Signaling session failure' (0x6) with
>>response code 'Requested policy rule denied due to policy
>>conflict' (0x4).  The MRI information is updated to reflect the
>> 
> 
> I think the change is good, but I notice you applied it to the NAT bullet, 
> and my comment was on the Firewall bullet. I suspect the same issue applies 
> to both?
> 


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

[Gen-art] Gen-ART LC Review of draft-turner-additional-cms-ri-choices-03

[Ben Campbell]

I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

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

Document: draft-turner-additional-cms-ri-choices-03
Reviewer: Ben Campbell
Review Date: 2010-04-16
IETF LC End Date: 2010-04-19
IESG Telechat date: (if known)

Summary: Very close to ready for publication as a proposed standard. I have a 
couple of mainly editorial questions.

Note: This draft contains ASN.1 definitions. I did not attempt to validate them 
mechanically.

Major issues: None

Minor issues: None

Nits/editorial comments:

-- Section 1, last sentence: "However, there MAY be more 
   revocation status information than necessary or there MAY be less 
   revocation status information than necessary."

Are those really normative statements, or just observations?

-- section 4, last paragraph, and section 5, last paragraph:

You mention the combination of "Unprotected and [/or] authenticated" responses 
a few times in these sections. Is that really meant to be "authenticated" 
rather than "unauthenticated"?

-- Appendices
 
Appendix A.1 is described as normative. I have a mild concern about readers 
reading far enough to normative material in an appendix. Would it make sense to 
have text in the main body that references the appendix as containing normative 
material?
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] LC review: draft-ietf-nsis-rmd-19.txt

[Joel M. Halpern]

I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

Document: draft-ietf-nsis-rmd-19.txt
RMD-QOSM - The Resource Management in Diffserv QOS Model
Reviewer: Joel M. Halpern
Review Date: 16-April-2010
IETF LC End Date: Done
IESG Telechat date:  22-April-2010

Summary: This document is ready for publication as an Experimental RFC.

PS: This is a re-review just looking for new problems, as the earlier 
drafts resolved all of my concerns.  The fiffs show that they made the 
requested changes, adn do not show any other cause for concern.



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