Subject: [Gen-art] Assignments for Dec 15th, 2005

From: "Mary Barnes" <[email-masked]>
Date: Thu, 8 Dec 2005 21:38:11 -0600

Here's the assignments for Dec 15th based on the agenda as of this
evening:
http://www.alvestrand.no/ietf/gen/art/reviewers-051215.html

with the corresponding spreadsheets available at:
http://www.alvestrand.no/ietf/gen/art/gen-art.html
http://www.alvestrand.no/ietf/gen/art/gen-art-by-reviewer.html

Let me know any if you see any errors or omissions.  Spencer, I've not
yet uploaded the reviews you sent today.

Also, a warning that I'll be doing a round of LC assignments tomorrow as
there's been over a dozen announced in the past 2 days.  

And, finally, I did update the FAQ and reviewer guidelines per Brian's
updates and subsequent discussion on the list.  
http://www.alvestrand.no/ietf/gen/art/review-guidelines.html
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html
Let me know if you see any issues with either of those and remember to
include the link to the FAQ in your reviews.

Thanks,
Mary.

_______________________________________________
Gen-art mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/gen-art

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 10 Dec 2005 15:23:25 -0500

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).

This document is ready for publication as a proposed standard.
There are some minor comments that the AD can review to decide if they are 
worth passing on to the working group.   (More significant comments are 
sent to authors, chairs, and WG list, but this is minor enough not to be 
worth risking confusion.)

minor:
     I am not sure calling section 2.0 "Requirements" is a good use of 
naming.  Section 2 is a really useful section.  It describes what you are 
trying to do nicely and clearly.  But "requirements" it 
isn't.  "Overview"would do nicely as a title.

     It seems to require interesting management control to achieve the 
conditions required to mix non-supporting RPs into this, as described in 
section 4.0.  I understand that technically, as long as the non-supporting 
RP has only receivers, it works.  But a little more explication as to when 
/ how this can be ensured might be appropriate.

     Isn't it a bit odd for the authors to thank themselves?  The work they 
are acknowledging is worth noting (the authors did two prototypes of the 
draft.)  But different wording might be nice.

-----------
RTG: Anycast-RP using PIM
     draft-ietf-pim-anycast-rp-04.txt

responsible AD: Bill Fenner
reviewer: Joel Halpern

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 10 Dec 2005 16:42:22 -0500

This document appears to be ready for publication as a proposed standard.
I do have one minor comment below.  This may be a result of the fact that I 
am not a security expert and may well have misread the document.

Minor:
The wording of section 6.1 describing the content of the REPLY message, 
section 6.3 text describing the CREATE message, the example of the CREATE 
sequence, and section 4.2.7 on KINK_ENCRYPT are subtly inconsistent.
a) The description of KINK_ENCRYPT should indicate that the inner types are 
the same as regular KINK types, and that KINK_ENCRYPT is specifically 
intended to be used as a wrapper around other KINK TLVs.
b) The description of the REPLY and CREATE messages should state that 
KINK_ENCRYPT is a valid TLV.  The wording lists a set of TLVs that are 
valid, and does not list KINK_ENCRYPT.

Yours,
Joel M. Halpern

[Multiple copies of comment sent according to gen-art procedures.]

----
SEC: Kerberized Internet Negotiation of Keys (KINK)
      draft-ietf-kink-kink-11.txt

Responsible AD: Sam Hartman
Reviewer: Joel Halpern

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 13 Dec 2005 14:37:54 -0500

This document is ready for publication as a proposed standard.
The concerns I had raised with version 10 have been fixed.

Yours,
Joel M. Halpern

----
INT encapsulation Methods for Transport of Ethernet Over MPLS Networks
     draft-ietf-pwd3-ethernet-encap-11.txt
AD: Mark Townsley
Reviewer: Joel Halpern

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 13 Dec 2005 17:24:49 -0500

This document is presumably ready for publication as whatever status the 
IESG thinks it should have.

Frankly, given that this document is a list of changes to a document I am 
not familiar with, my reading was a surface review to see if anything leapt 
out at me.  I presume that there is a good reason why the tsvwg or SCTPwg 
did not revise 2960 instead of issuing 100 pages of errata.  I personally 
find documents like this almost useless, even when I know the space.

I confess that having found the writeup, and read Allison / James comments, 
I am left with the distinct impression that this is a Proposed 
Standard.  As far as I can tell, the import of this document is that folks 
should take apply these changes when implementing RFC 2960.  The document 
says "this is a compilation of all defects".  Pretending this is 
"informational" seems a bad idea.

Yours,
Joel M. Halpern

----
TRANS Stream Control Transmission Protocol (SCTP) Specification Errata and 
Issues
     draft-ietf-tsvwg-sctpimpguide-16.txt

AD: Allison Mankin
Reviewer: Joel Halpern

---

From: Shoichi Sakane <[email-masked]>
Date: Wed, 14 Dec 2005 11:39:07 +0900

Hi,

Section 4 explains the format of each KINK payload.  Section 6 explains
the structure of each KINK message.  I agree that tehre is no description
about the contents of "Payload" of KINK_ENCRYPT.
Would it be enough if there was the following text into section 4.2.7 ?

	The construction encapsulated in the payload of KINK_ENCRYPT
	describes at section 6.

---

From: Scott W Brim <[email-masked]>
Date: Wed, 14 Dec 2005 08:17:35 -0500

Mary, you had better reduce my limit by 1.  I'm obviously
overestimating my available time.  Sigh.  Thanks.

(This time I thought I would have two days of boring conference calls
during which I could do reviews, but it turned out that there were
many issues I had to argue about.)

---

From: Scott W Brim <[email-masked]>
Date: Wed, 14 Dec 2005 08:44:52 -0500

No obj.  Ted covered the one interesting point.

---

From: Elwyn Davies <[email-masked]>
Date: Wed, 14 Dec 2005 20:52:48 +0000

Do you want me to do a quick pass on the tesla-bootstrapping draft (bit 
on the late side) but if Scott is too busy.. I know something about 
tesla already and I had a quick look at this draft when doing my 
previous tesla stuff.

Elwyn

---

From: Scott W Brim <[email-masked]>
Date: Wed, 14 Dec 2005 16:38:16 -0500

> tesla already and I had a quick look at this draft when doing my

I'm at the "looks good but I should investigate its context" stage.
If you want to take it that would be wonderful.  So far I don't see
anything wrong.

Thanks ... Scott

---

From: Elwyn Davies <[email-masked]>
Date: Wed, 14 Dec 2005 22:33:32 +0000

OK.. I'll take it.

E

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 15 Dec 2005 10:30:54 +0100

Thanks. That led to a DISCUSS btw - Elwyn spotted some data items
that seem to be underspecified for interoperability purposes.

    Brian

---

From: Scott W Brim <[email-masked]>
Date: Fri, 16 Dec 2005 14:05:54 -0500

No objection.  (Not much time either -- sorry folks)

I did not follow up on the assumption that SDP descriptions are
secure.  I don't know much about this space but it appears that they
are proud of their work in SDP security.  If that's true (and I
believe it) then this draft looks okay to me.  The IESG has already
discussed the issue with some of the references apparently being downrefs.