headers
Miguel A. Garcia | 1 Oct 2009 15:46
Picon
Favicon

Gen-ART review of draft-ietf-mpls-tp-gach-dcn-06.txt

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-ietf-mpls-tp-gach-dcn-06.txt
Reviewer: Miguel Garcia <miguel.a.garcia <at> ericsson.com>
Review Date: 01-October 2009	
IETF LC End Date: 05-October-2009

Summary: The document is ready for publication as a standards track RFC.

The document is clearly written and is ready for publication.

/Miguel
--

-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain
Permalink | Reply | 0 comments |
headers
Sean Turner | 1 Oct 2009 17:55

GEN-Art review of draft-ietf-ccamp-mpls-graceful-shutdown

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-ietf-ccamp-mpls-graceful-shutdown
Reviewer: Sean Turner
Review Date: 2009-10-01
IETF LC End Date: 2009-10-05
IESG Telechat date: N/A

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

Comments: None.

spt
Permalink | Reply | 0 comments |
headers
Ben Campbell | 1 Oct 2009 23:09

Re: Gen-ART LC review of draft-ietf-ancp-framework-10

Oops, sorry for the late response. This one ran afoul of my mail  
filters for some reason.  Comment inline:

On Sep 25, 2009, at 7:45 AM, OOGHE Sven wrote:

> Ben,
>
> Apologies for the late reply - I lost track of this email.
>
> I think the requirement below comes a bit "after the fact" in the  
> sense
> that it used to be relevant at a time when a protocol selection was
> performed. Meanwhile the IETF has specified the ANCP protocol (based  
> on
> GSMP), so this requirement has lost most of its relevance.
>
> The very high level requirement would be:
>
> "The ANCP MUST be designed in such a way that it is simple and
> lightweight."
>
> I agree that it's pretty hard to evaluate compliance or non-compliance
> to such a requirement. So in that case, I propose to omit it.
>

I do not object to removing it.

> Regards
> Sven
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mary Barnes | 2 Oct 2009 05:18
Favicon

Assignments for Oct 8th, 2009 Telechat

Hi all,

Here's the link to the summary of assignments for the Oct. 8th, 2009 telechat:
http://www.softarmor.com/rai/temp-gen-art/reviewers-091008.html

I have not yet uploaded the spreadsheets or recent reviews - I'm still working on those, along with the new last call assignments. I'll post all of that once I can get back to it tomorrow (likely afternoon since I have nomcom stuff to do in the morning).  Sorry, but I've been pretty sick the last couple of days - thought it was allergies, but just found out today it's pneumonia, so it's taking me a while to get stuff done.

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: 8 Oct 2009

Summary:

Major issues:
Minor issues:
Nits/editorial comments: 
















_______________________________________________
Gen-art mailing list
Gen-art <at> ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
Permalink | Reply | 0 comments |
headers
Francis Dupont | 2 Oct 2009 10:45
Picon

review of draft-ietf-roll-building-routing-reqs-07.txt

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-ietf-roll-building-routing-reqs-07.txt
Reviewer: Francis Dupont
Review Date: 2009-09-29
IETF LC End Date: 2009-09-24
IESG Telechat date: unknown

Summary: Ready

Major issues: None

Minor issues:
 - IMHO the document is a bit USA centric (but it is not a problem
  if it is stated in the document, for instance with a reference
  from the (US) building automation community, cf 8.2 comment below)

Nits/editorial comments: 
 - the language of the document is not at the usual level (but at it
  should be considered as better it is not a concern)
 - 2 page 4, 5.1 and 5.1.1 page 12, 5.3 page 13, 5.4.1 and 5.4.2 page 14.
  5.7.2 and 5.7.4 page 16, 5.7.7 page 17. 5.8.4 page 18, 9.2.1 page 20:
   e.g. -> e.g.,
 - 3.1 page 5: use the occasion to introduce the FMS abbrev, i.e.,
  add "(MS)" after "facility management system"
 - 4 page 10: the P in P2P (and MP2P / P2MP) is ambiguous:
  it can stand for point and the point-to-point term usually
  refers to link topology. I propose:
   P2P -> (peer-to-peer, P2P)
   (MP2P) -> (multi-peers-to-peer, MP2P)
   (P2MP) -> (peer-to-multi-peers, P2MP)
 - 4 page 10 and 5.4.3 page 14: acknowledgement -> acknowledgment
  (for uniformity with the section title where this spelling is
   enforced) (multiple occurrences)
 - 5.1 page 11: no network knowledge -> no communication network knowledge
 - 5.2.2 page 13: even it is also overloaded:
  point-to-point -> end-to-end
 - 5.4 page 14: i.e. -> i.e.,
 - 5.4.3 page 14: 2000mah -> 2000mAh
 - 5.7.6 page 17: msec -> ms
 - 7 page 19: J. P. -> JP.
 - 8.2 page 19: I'd really like to get a reference from the building
 automation community: explaining networking to them or an introduction
 for us (networking community) or both. I expect there are at least
 some framework standards.
 - 9.1.2 page 19: 2.4Ghz -> 2.4GHz
  (BTW the ISM band text is very USA centric :-)
 - 9.3.1 page 20: missing final '.'
 - Authors' Addresses page 22: unfinished (???), add +1 for USA phone
 number, -- -> - (and BTW try to use the same separator)

Regards 

Francis.Dupont <at> fdupont.fr
Permalink | Reply | 5 comments |
headers
Alexey Melnikov | 2 Oct 2009 19:14
Favicon

Re: Gen-ART LC Review of draft-ietf-sasl-scram-07

Hi Ben,
Thank you for your comments. Responding to most of them below (I will
respond to the rest in a separate message).

On Thu, Sep 24, 2009 at 2:22 AM, Ben Campbell <ben <at> estacado.net> wrote:
> 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-ietf-sasl-scram-07
> Reviewer: Ben Campbell
> Review Date: 2009-08-23
> IETF LC End Date: 2009-08-28
> IESG Telechat date: (if known)
>
> Summary:
>
> This draft is almost ready for publication as a proposed standard. I have a
> few questions and editorial comments that might be worth considering prior
> to publication.
>
> Major issues:
>
> None.
>
>
> Minor issues:
>
> - Section 2, 1st paragraph: "...addresses the requirements necessary to
> deploy a challenge- response mechanism more widely than past attempts."
>
> What are these requirements? Are they documented somewhere? Do you mean for
> appendix A or B to express them?

Yes. I've added forward references.

[...]

> I'm no crypto expert, so please forgive me if this is silly--but isn't there
> a movement to phase out sha-1? If so, should that be the default "must
> implement" hash for a new mechanism?

My understanding is that use of SHA-1 under HMAC is still considered reasonable.
The WG debated at length use of SHA-1 versa use of SHA-256, etc. and decided
to proceed with SHA-1, because it is more frequently implemented in libraries
and hardware.

> -- section 5.1, definition of "r:", "It is important that this value be
> different for each authentication."
>
> Are there any best practices for nonce generation that can be mentioned or
> referenced?

The reference to RFC 4086 is already present elsewhere in the document,
but I added it here.

> -- Section 9, 1st paragraph:
>
> Can you describe the required properties expected from a "strong security
> layer"? (i.e. confidentiality, integrity protection, etc.)

I've added "(such as TLS with data confidentiality)". I hope this is clearer.

 [...]

> --3rd paragraph:
>
> I gather you are saying that there are techniques that mitigate the damage
> of a stolen authorization database, but the work group chose not to use
> them. Can you elaborate on the wg motivation for not doing so?

IPR claims on authentication mechanisms such as SRP.
Text commenting on IPR was removed as per Pasi's request.

> Nits/editorial comments:
>
> -- 1.1, 2nd bullet: Can you include an informational reference for RADIUS?

Added.

> -- 1.2, last bullet:
>
> What is the referent for "this"? Is there perhaps a missing word(s), or
> maybe this paragraph belongs with the previous bullet?

The latter. (This == Hi())

> -- 2, last paragraph:
>
> Do you plan for this paragraph to stay in the RFC? Is the work group mail
> list permanent enough to be published in the RFC?

Deleted.

> -- 5.1, definition of "c:", 2nd bullet: "(recall: a channel binding flag and
> an optional authzid.)
>
> I'm not sure I follow the sentence. Do you mean to say something like
> "Recall the G2 header contains a..."

Yes. Changed.

> -- IDNits reports the following:
>
>  == Outdated reference: A later version (-03) exists of
>     draft-melnikov-sasl-scram-ldap-02

The two documents would be published simultaneously, so this will go away
during editing by the RFC Editor.

> It also reports a number of false errors about undefined references. I think
> it's confused by your non-standard reference sections, which I think make
> sense under the circumstances.

Right.

Regards,
Alexey
Permalink | Reply | 3 comments |
headers
nicolas.riou | 2 Oct 2009 19:03

RE review of draft-ietf-roll-building-routing-reqs-07.txt


Hi Francis,

Can you precise a little bit more why you think draft 07 is USA centric? Mainly because of section 8.2 and section 9.1.2? other sections?

Regarding section 8.2, I don't fully understand your expectation... Do you expect a few words on LON / Echelon, ASHRAE... for instance?

Have a nice week-end & Best regards,
Nicolas






Francis Dupont <Francis.Dupont <at> fdupont.fr>
Envoyé par : Francis.Dupont <at> fdupont.fr

02/10/2009 10:45

A
 gen-art <at> ietf.org
cc
 jerald.p.martocci <at> jci.com, Nicolas Riou/FR/Schneider <at> Europe, pieter.demil <at> intec.ugent.be, wouter <at> vooruit.be, adrian.farrel <at> huawei.com
Objet
 review of draft-ietf-roll-building-routing-reqs-07.txt





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-ietf-roll-building-routing-reqs-07.txt
Reviewer: Francis Dupont
Review Date: 2009-09-29
IETF LC End Date: 2009-09-24
IESG Telechat date: unknown

Summary: Ready

Major issues: None

Minor issues:
- IMHO the document is a bit USA centric (but it is not a problem
 if it is stated in the document, for instance with a reference
 from the (US) building automation community, cf 8.2 comment below)

Nits/editorial comments:
- the language of the document is not at the usual level (but at it
 should be considered as better it is not a concern)
- 2 page 4, 5.1 and 5.1.1 page 12, 5.3 page 13, 5.4.1 and 5.4.2 page 14.
 5.7.2 and 5.7.4 page 16, 5.7.7 page 17. 5.8.4 page 18, 9.2.1 page 20:
  e.g. -> e.g.,
- 3.1 page 5: use the occasion to introduce the FMS abbrev, i.e.,
 add "(MS)" after "facility management system"
- 4 page 10: the P in P2P (and MP2P / P2MP) is ambiguous:
 it can stand for point and the point-to-point term usually
 refers to link topology. I propose:
  P2P -> (peer-to-peer, P2P)
  (MP2P) -> (multi-peers-to-peer, MP2P)
  (P2MP) -> (peer-to-multi-peers, P2MP)
- 4 page 10 and 5.4.3 page 14: acknowledgement -> acknowledgment
 (for uniformity with the section title where this spelling is
  enforced) (multiple occurrences)
- 5.1 page 11: no network knowledge -> no communication network knowledge
- 5.2.2 page 13: even it is also overloaded:
 point-to-point -> end-to-end
- 5.4 page 14: i.e. -> i.e.,
- 5.4.3 page 14: 2000mah -> 2000mAh
- 5.7.6 page 17: msec -> ms
- 7 page 19: J. P. -> JP.
- 8.2 page 19: I'd really like to get a reference from the building
automation community: explaining networking to them or an introduction
for us (networking community) or both. I expect there are at least
some framework standards.
- 9.1.2 page 19: 2.4Ghz -> 2.4GHz
 (BTW the ISM band text is very USA centric :-)
- 9.3.1 page 20: missing final '.'
- Authors' Addresses page 22: unfinished (???), add +1 for USA phone
number, -- -> - (and BTW try to use the same separator)

Regards

Francis.Dupont <at> fdupont.fr

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
______________________________________________________________________

_______________________________________________
Gen-art mailing list
Gen-art <at> ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
Permalink | Reply | 2 comments |
headers
Alexey Melnikov | 2 Oct 2009 19:31
Favicon

Re: Gen-ART LC Review of draft-ietf-sasl-scram-07

On Thu, Sep 24, 2009 at 2:22 AM, Ben Campbell <ben <at> estacado.net> wrote:
 [...]
> Minor issues:
 [...]
> -- section 4, first paragraph: "...as long as this alternative name doesn’t
> conflict with any other hash function name from the IANA "Hash Function
> Textual Names" registry."
>
> What prevents future conflicts if someone registers a name that conflicts
> with the short name?

Good point.

> Should the short-names be IANA registered to prevent
> this?

This is a good idea. I've added:
  Such alternative name SHOULD be registered in the IANA
  "Hash Function Textual Names" registry.

> (Should future names be limited to 9 chars?)

I would rather not put extra restrictions on another registry due to
limitations on SASL mechanism names.

I would also note that the likelyhood of registering another SCRAM
mechanism name is quite low, and the likelyhood of the conflict
described above is even lower, so I wouldn't worry too much about this
case anyway.
Permalink | Reply | 1 comment |
headers
Ben Campbell | 2 Oct 2009 19:50

Re: Gen-ART LC Review of draft-ietf-sasl-scram-07

Hi Alexey,

Your responses in this and your other email address all of my comments.

Thanks!

Ben.

On Oct 2, 2009, at 12:31 PM, Alexey Melnikov wrote:

> On Thu, Sep 24, 2009 at 2:22 AM, Ben Campbell <ben <at> estacado.net>  
> wrote:
> [...]
>> Minor issues:
> [...]
>> -- section 4, first paragraph: "...as long as this alternative name  
>> doesn’t
>> conflict with any other hash function name from the IANA "Hash  
>> Function
>> Textual Names" registry."
>>
>> What prevents future conflicts if someone registers a name that  
>> conflicts
>> with the short name?
>
> Good point.
>
>> Should the short-names be IANA registered to prevent
>> this?
>
> This is a good idea. I've added:
>  Such alternative name SHOULD be registered in the IANA
>  "Hash Function Textual Names" registry.
>
>> (Should future names be limited to 9 chars?)
>
> I would rather not put extra restrictions on another registry due to
> limitations on SASL mechanism names.
>
> I would also note that the likelyhood of registering another SCRAM
> mechanism name is quite low, and the likelyhood of the conflict
> described above is even lower, so I wouldn't worry too much about this
> case anyway.
Permalink | Reply | 0 comments |
headers
Nicolas Williams | 2 Oct 2009 20:17
Picon

Re: Gen-ART LC Review of draft-ietf-sasl-scram-07

On Fri, Oct 02, 2009 at 06:14:47PM +0100, Alexey Melnikov wrote:
> On Thu, Sep 24, 2009 at 2:22 AM, Ben Campbell <ben <at> estacado.net> wrote:
> > I'm no crypto expert, so please forgive me if this is silly--but isn't there
> > a movement to phase out sha-1? If so, should that be the default "must
> > implement" hash for a new mechanism?
> 
> My understanding is that use of SHA-1 under HMAC is still considered reasonable.
> The WG debated at length use of SHA-1 versa use of SHA-256, etc. and decided
> to proceed with SHA-1, because it is more frequently implemented in libraries
> and hardware.

This matter has come up elsewhere, such as in the KRB-WG.  NIST has not
obsoleted the use of HMAC-SHA-1, though I don't have a reference handy
at the moment (but a quick search of the KRB-WG mailing list and, maybe,
the krbdev <at> mit.edu list should yield one).

> > -- 1.2, last bullet:
> >
> > What is the referent for "this"? Is there perhaps a missing word(s), or
> > maybe this paragraph belongs with the previous bullet?
> 
> The latter. (This == Hi())

Incidentally, Hi() should be shown as taking the iteration count as an
argument.

Nico
--

--
Permalink | Reply | 2 comments |

Gmane