review of draft-eastlake-sha2-01.txt

Brian filed a discuss on this - I agree with it:

>Discuss:
>11. Security Considerations
>
>    This document is intended to provide convenient open source access
by
>    the Internet community to the United States of America Federal
>    Information Processing Standard Secure Hash Algorithms (SHAs) [FIPS
>    180-2] and HMACs based thereon.
>
>"open source access"? RFCs don't carry an open source license. 
>I believe this should just read "open access".

I note that the Abstract says:

Abstract

   The United States of America has adopted a suite of secure hash
   algorithms (SHAs), including four beyond SHA-1, as part of a Federal
   Information Processing Standard (FIPS), specifically SHA-224 [RFC
   3874], SHA-256, SHA-384, and SHA-512.  The purpose of this document
   is to make open source code performing these hash functions
   conveniently available to the Internet community.  ....

I think this should be updated accordingly as well.

John

review of draft-ietf-mpls-nodeid-subobject-07.txt

Here is my review:

This seems ready for publication, however there are some nits to fixed
and I have
one open question:

Nits found, ID nits checker output at the end of this mail

Where will the nodeid subobject defined? Should it be registered in IANA
or
elsewhere?

John 

dnits 1.85 

tmp/draft-ietf-mpls-nodeid-subobject-07.txt:

  Checking nits according to http://www.ietf.org/ID-Checklist.html:

    Checking conformance with RFC 3978/3979 boilerplate...

  * The document seems to lack an RFC 3978 Section 5.4 Copyright Line --
    however, there's a paragraph with a matching beginning. Boilerplate
error?

    RFC 3978 Section 5.4 paragraph 1 text:
    "Copyright (C) The Internet Society (2006)."

    ... text found in draft:

Re: review of draft-eastlake-sha2-01.txt

Yes, and in fact there is already an RFC Editor note
to fix this, and also a -02 version, so I was able to clear
my discuss. (We had an IESG retreat Monday and Tuesday,
so a number of discusses got cleared during coffee breaks.)

Thanks

     Brian

john.loughney <at> nokia.com wrote:
> Brian filed a discuss on this - I agree with it:
> 
> 
>>Discuss:
>>11. Security Considerations
>>
>>   This document is intended to provide convenient open source access
> 
> by
> 
>>   the Internet community to the United States of America Federal
>>   Information Processing Standard Secure Hash Algorithms (SHAs) [FIPS
>>   180-2] and HMACs based thereon.
>>
>>"open source access"? RFCs don't carry an open source license. 
>>I believe this should just read "open access".
> 
> 
> I note that the Abstract says:
> 

Re: Assignments for Feb 2nd, 2006

Thanks everybody! I got all my ballots done by Wednesday at 11:16 EST.
As a matter of interest, they came out as 14 No Objections,
1 DISCUSS that has already been resolved, and 1 DISCUSS still
in place. That seems to be a better than average crop of drafts;
I think there's reason to believe that the LC reviews are having
an effect.

     Brian

Brian E Carpenter wrote:
> Please note that
> a) I will be on travel for an IESG retreat in the early part
> of next week. In particular I will be off line after about 11:00 PST
> on Wednesday - so reviews that aren't sent at the latest Wednesday
> morning (US time) won't be used.
> 
> b) Because of some stupid flight arrangements I'll almost certainly
> miss the telechat on Thursday. But subject to the above, I will try to
> get all my ballots in on Wednesday.
> 
> Thanks
> 
>    Brian
> 
> Mary Barnes wrote:
> 
>> Here's the assignments for the Feb 2nd, 2006 telechat, based on the
>> agenda as of this evening: 
>> http://www.alvestrand.no/ietf/gen/art/reviewers-060202.html
>> with the corresponding spreadsheets available at: 

A *new* batch of IETF LC reviews - Feb 1st, 2006

Hi all,

Here's the latest round of LC assignments: 
http://www.alvestrand.no/ietf/gen/art/gen-art.html 
http://www.alvestrand.no/ietf/gen/art/gen-art-by-reviewer.html 

Thanks, 
Mary. 

--------------------------- 
Reviewer: Elwyn Davies

- 'OCSP Support for PKINIT '
   <draft-ietf-krb-wg-ocsp-for-pkinit-06.txt> as a Proposed Standard
- 'Public Key Cryptography for Initial Authentication in Kerberos '
   <draft-ietf-cat-kerberos-pk-init-33.txt> as a Proposed Standard

This document includes normative references to two informational RFCs;
per RFC 3967 these references are noted in the last call. Both these
references are common in security protocols and may not be noted in
future last calls.

[RFC2412] Orman, H., "The OAKLEY Key Determination Protocol", RFC
2412, November 1998. (Included for the definitions of the OAKLEY
Diffie-Hellman
groups)

[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography
Standards (PKCS) #1: RSA Cryptography Specifications
Version 2.1", RFC 3447, February 2003.

Re: GEN-ART review of draft-ietf-ccamp-loose-path-reopt-01

Hi Harald,

Many Thanks for the comments ... and sorry for responding so late ...  
See in line,

On Nov 3, 2005, at 11:34 AM, Harald Tveit Alvestrand wrote:

> <I'm assuming people know about gen-art by now. If not - ask.>
>
> Document: draft-ietf-ccamp-loose-path-reopt-01
> Reviewer: Harald Alvestrand
> Date: November 3, 2005
>
> Summary: Technology ready for Proposed, presentation could use work
>
> Once I understood what this document's driving at, it's a  
> refreshingly simple idea: Let intermediate nodes tell the headend  
> node that a better (G)MPLS path might be available, and let the  
> headend node have a way to get the intermediate nodes to look for one.
>
> I think this is well captured in the last half of the abstract:
>
>   This document proposes a
>   mechanism that allows a TE LSP head-end LSR to trigger a new path  
> re-
>   evaluation on every hop having a next hop defined as a loose or
>   abstract hop and a mid-point LSR to signal to the head-end LSR  
> that a
>   better path exists (compared to the current path in use) or that the
>   TE LSP must be reoptimized because of some maintenance required on

Re: Gen-ART Review of draft-ietf-tcpm-tcp-roadmap-05

Spencer-

Remind me ... gen-art assignments are random, right?  This one seems to
fall in the "there is no such thing as a 'coincidence'" pile. 

I iterated with a couple of the authors (Wes & Ethan).  None of us
really understands how we skipped 3 of the PILC RFCs.  (This is
particularly embarrassing for me.)  But, Ethan is going to write some
stuff for these RFCs and will look over the tweaks you suggested, too, I
am sure.

Some day this "simple" non-engineering document may be done ... 

Thanks a bunch for the review.

allman

_______________________________________________
Gen-art mailing list
Gen-art <at> ietf.org
https://www1.ietf.org/mailman/listinfo/gen-art

Re: Gen-ART Review of draft-ietf-tcpm-tcp-roadmap-05

Dear Mark,

Apparently some Gen-ART review assignments are more random than others 

I do share your pain on forgetting the PILC documents, because I hadn't 
really been thinking about whether they would be present until I saw RFC 
2757 and thought, "why is that one in there?", and then started counting.

This is just more proof that no one completely understood the document set 
until you guys started the non-engineering document, of course!

Thanks,

Spencer 

draft-ietf-l2tpext-l2vpn-06.txt

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

Document: draft-ietf-l2tpext-l2vpn-06.txt
Intended Status: Proposed Standard (WG submission)
Shepherding AD: Mark Townsley
Review Trigger: IETF last call ended 23 Jan 2006

Summary:
This document is close to being ready for PS.  It has one minor issue 
relating to the M bit in the various AVPs (see below) and its 
readability/usefulness could be much improved by pointers to the 
relevant parts of RFC3931 for definitions and processes referred to.  It 
also could do with a terminology section to make it clear where all the 
various terms come from and expand some of the acronyms.

Minor issues:

M bit in AVPs:
==============
s4.3: In the description of the new AVPs, the M bit is specified as 
SHOULD be 0 for all three items i.e. the receiver should ignore the AVP 
if it doesn't understand it.  Two questions (one with two parts) come to 
mind:
- For each AVP, will everything work as expected if the sender includes 
the AVP and the receiver ignores it?  Should the behaviours in this 
eventuality be discussed?
- What circumstances would lead an implementer to set the M bit to 1?

Re: LC Review Assignment: RAQMON

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

Framework:
http://www.ietf.org/internet-drafts/draft-ietf-rmonmib-raqmon-framework-14.txt
This document is nearly ready for publication as a proposed standard.
(If I am confused about the congestion section, then it is ready for 
publication.)

Moderate:  Congestion...
Has the congestion safety section been reviewed by a transport area 
congestion expert?
It seems to me that the description in section 3, bullet 1, of the 
use of a constant Transmission rate ought to indicate that the rate 
needs to be related to the expected peak number of devices.  (After 
all, the earlier text did talk about the fan in problem.)  Based on 
routing protocol experience, it may also want to indicate that the 
timer for the constant rate needs to be randomly jittered.
The title of section 3, bullet 2 (retransmission timers with back 
offs) seems misleading.  If I am reading the text right, the actual 
technique is to send one message, and wait for a response before 
sending another.  What one might call "single outstanding 
request."  There is nothing in the text about retransmissions and 
back-offs.  (Although, such a technique does require retransmissions, 
and such retransmissions must be backed off.  That is secondary to 
the core of the technique, but ought to be mentioned.)
Section 3, bullet 3 is about avoiding fragmentation.  While that is a 
useful technique, it does not seem to me that it is a congestion 
avoidance technique.