Subject: [Gen-art] A *new* batch of IETF LC reviews - Sept 10th

From: "Mary Barnes" <[email-masked]>
Date: Sat, 10 Sep 2005 18:26:03 -0500

Here's the assignment of the most recent IETF LCs, along with the
updated spreadsheets:
http://www.alvestrand.no/ietf/gen/art/gen-art.html
http://www.alvestrand.no/ietf/gen/art/gen-art-by-reviewer.html

Mary.

------------------------ 
Reviewer: Harald Alvestrand

- 'IRIS - An Address Registry (areg) Type for the Internet Registry
Information 
   Service '
   <draft-ietf-crisp-iris-areg-12.txt> as a Proposed Standard

IETF LC ends on 2005-09-21.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-crisp-iris-areg-12.txt

------------------------ 
Reviewer: Joel Halpern

- 'IANA Considerations for LDAP '
   <draft-ietf-ldapbis-bcp64-05.txt> as a BCP

IETF LC ends on 2005-09-21.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-ldapbis-bcp64-05.txt

------------------------ 
Reviewer: John Loughney

- 'Avoiding Equal Cost Multipath Treatment in MPLS Networks '
   <draft-ietf-mpls-ecmp-bcp-01.txt> as a BCP

IETF LC ends on 2005-09-21.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-mpls-ecmp-bcp-01.txt

------------------------
Reviewer: Lakshminath Dondeti

- 'M-ISIS: Multi Topology (MT) Routing in IS-IS '
   <draft-ietf-isis-wg-multi-topology-10.txt> as a Proposed Standard

IETF LC ends on 2005-09-21.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-isis-wg-multi-topology-10
.txt

------------------------ 
Reviewer: Mark Allman

- 'Definitions of Managed Objects For iFCP '
   <draft-ietf-ips-ifcp-mib-06.txt> as a Proposed Standard

IETF LC ends on 2005-09-22.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-ips-ifcp-mib-06.txt

------------------------ 
Reviewer: Spencer Dawkins

- 'DHCP over InfiniBand '
   <draft-ietf-ipoib-dhcp-over-infiniband-10.txt> as a Proposed Standard

IETF LC ends on 2005-09-23.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-ipoib-dhcp-over-infiniban
d-10.txt

------------------------
Reviewer: Avri Doria

- 'Definitions of Managed Objects for Bridges with Traffic Classes,
Multicast 
   Filtering and Virtual LAN Extensions '
   <draft-ietf-bridge-ext-v2-07.txt> as a Proposed Standard

IETF LC ends on 2005-09-23.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-bridge-ext-v2-07.txt

------------------------    

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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 10 Sep 2005 22:22:07 -0400

[This is a gen-art review prepared for the IETF chair by a pseudo-randomly 
selected member of the gen-art team.
  This review is intended to help the IETF Chair / General AD.  It is 
provided directly to the other affected individuals to
  save confusion.]

This document is nearly ready for publication as a BCP.

Question: Based on the issues that have been raised about reviews recently, 
should this document be more specific as to what kinds of issues the expert 
reviewer is to look for in each kind of item to be reviewed, and why?  (I 
am not arguing with the WGs choice of mechanism, just trying to head off 
trouble that can be foreseen.)

Question: Is the last sentence of the second paragraph of 3.4 intended to 
call for expert review of all descriptors, or only of descriptors 
referencing different object identifiers from an already registered 
descriptor with the same name?  While I find this verbiage awkward in the 
other places it is used, this particular usage is less clear than the others.

Editorial: In section 3, the word "expecting" is almost certainly "excepting".

idnits: (I note that the base document is 13 pages, but it probably should 
have a ToC anyway.)

   * Found rfc3978 Section 5.4 paragraph 1 boilerplate (on line 909), which
     is fine, but *also* found rfc2026 Section 10.4C paragraph 1 boilerplate on
     line 43. It should be removed.
   * The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure
     Acknowledgement -- however, there's a paragraph with a matching beginning.
     Boilerplate error?
     (The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate
     instead of verbatim RFC 3978 boilerplate.  After 6 May 2005, submission of
     drafts without verbatim RFC 3978 boilerplate is not accepted.)
   * The document is more than 15 pages and seems to lack a Table of
     Contents.
   * There are 35 instances of too long lines in the document, the longest
     one being 6 characters in excess of 72.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 27 Sep 2005 11:46:22 -0700

At 07:22 PM 9/10/2005, Joel M. Halpern wrote:
>[This is a gen-art review prepared for the IETF chair by a pseudo-randomly selected member of the gen-art team.
> This review is intended to help the IETF Chair / General AD.  It is provided directly to the other affected individuals to
> save confusion.]
>
>Question: Based on the issues that have been raised about reviews recently, should this document be more specific as to what kinds of issues the expert reviewer is to look for in each kind of item to be reviewed, and why?  (I am not arguing with the WGs choice of mechanism, just trying to head off trouble that can be foreseen.)

As the IESG-designated 'Expert Reviewer' for LDAP parameters,
I don't forsee there being significant trouble due to the
level of guidance given.  I think the BCP64 adequately covers
specific issues.  While there might be some general issues:
"do no harm (to the internet)"), "focus on the request, not
the specification", etc., I don't see the need to discuss
these in BCP64 as none of its specific to LDAP registrations.

Its my view that one of the key reasons we rely on IESG
selected experts is to reduce the need to be overly precise
in the guidance.

I suggest that we focus only on LDAP-specific issues.
If you have any, please elaborate.

>Question: Is the last sentence of the second paragraph of 3.4 intended to call for expert review of all descriptors, or only of descriptors referencing different object identifiers from an already registered descriptor with the same name?  While I find this verbiage awkward in the other places it is used, this particular usage is less clear than the others.

The intent of the paragraph:
  While the protocol allows the same descriptor to refer to different
  object identifiers in certain cases and the registry supports
  multiple registrations of the same descriptor (each indicating a
  different kind of schema element and different object identifier),   
  multiple registrations of the same descriptor are to be avoided. 
  All such registration requests require Expert Review. 

is to note that while the registry supports non-unique descriptors
(but unique within their category of use), registration of a
non-unique descriptor is to be avoided and, hence, requires
expert review.  That is, if you want to register e-foo
both as an attribute type descriptor and as an object class
descriptor, the policy is Expert Review (instead of
First Come First Server for other e- descriptors).

Please feel free to offer a specific suggestion (e.g., text) to
help clarify this paragraph.   The current text is the best I
could come up at the time (and at this time).

Editorial/nits issues noted will be appropriately addressed.

Thanks for the review, Kurt.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 27 Sep 2005 21:24:06 -0400

Thank you for clarifying the intent.
I would suggest changing the last sentence by adding a word, to read:
"All such multiple registration requests require expert review."
My problem was that I could read the "such" as refering to either part of 
the paragraph.

Thank you,
Joel

At 02:46 PM 9/27/2005, Kurt D. Zeilenga wrote:
> >Question: Is the last sentence of the second paragraph of 3.4 intended 
> to call for expert review of all descriptors, or only of descriptors