Sharon Chisholm | 2 Mar 02:26 2007

Gen-art review of draft-ietf-iptel-tgrep-08.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: A Telephony Gateway Registration Protocol (TGREP)
Summary: This document is ready for publication, but has the following
nits that should be resolved.

Comments
---------

1. In section 1, in the definition of a trunk, replace "In a network, a
communication path connecting " with 'In a network, a trunk is a
communication path connecting". 

2. In section 2, first sentence, replace "has already gone through TRIP
[2]" with "is familiar with TRIP [2]"

3. In a number of sections there seems to be confusion between use of
'that' and 'which'. ('That' should used to disambiguate. The car that is
yellow. My car, which I drove to the ski hill.). Places include: section
3, first paragraph, 4th sentence; section 7, first paragraph; section
7.2, first sentence

4. In section 3, first paragraph, 4th sentence, replace with "A TGREP
Receiver is defined, which receives this information and optionally
performs operations like consolidation and aggregation, hands over the
(Continue reading)

Mary Barnes | 2 Mar 03:51 2007

Review assignments for 08 Month 2007

Hi all,

Here's the assignments for the March 8th, 2007 telechat:
http://www.alvestrand.no/ietf/gen/art/reviewers-070308.html

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

For your convenience, the review boilerplate template is included below.

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: 08 March 2007

Summary:

Comments:
(Continue reading)

Mary Barnes | 2 Mar 03:51 2007

A *new* batch of IETF LC reviews - 1 March 2007

Hi all,

Here's this week's LC assignments: 
http://www.alvestrand.no/ietf/gen/art/gen-art.html 
http://www.alvestrand.no/ietf/gen/art/gen-art-by-reviewer.html 

The standard template is included at the end of the assignments.  

Thanks, 
Mary. 

--------------------------- 
Reviewer: Suresh Krishnan

- 'A Policy Control Mechanism is IS-IS Using Administrative Tags '
   <draft-ietf-isis-admin-tags-03.txt> as a Proposed Standard

This document has a normative reference to an informational
requirements RFC: RFC 2702 (Requirements for Traffic Engineering
Over MPLS).

In addition, it has normative references to 2 informational RFCs,
2966 and 3784.  These are part of a group of informational RFCs that
were published as informational instead of standards-track for
historical reasons, and there is current work in progress to advance
them to standards track.  However, to avoid unnecessary delay for
this document, the IESG proposes using a combination of the RFC
3967 rule (this Last Call) and the annotation described in section
4 of draft-klensin-norm-ref (currently in Last Call).  The annotation
will read:
(Continue reading)

Spencer Dawkins | 2 Mar 05:54 2007

Gen-ART Review of draft-ietf-avt-hc-over-mpls-protocol-08

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-avt-hc-over-mpls-protocol-08
Reviewer: Spencer Dawkins
Review Date: 2007-03-01
IETF LC End Date: 2007-02-07
IESG Telechat date: 2007-03-08

Summary: This document is ready for publication as Proposed Standard.

Just to follow up - 08 addressed all but one of my Last Call concerns from 
07, and Jerry provided text (below) that addressed the last concern.

> If you prefer I could replace the phrasing "These sub-options do not
> occur together" with the following text: "These sub-options MUST NOT
> occur together, if they do (e.g., if misconfigured) a decompressor MUST
> reject this option and send an explicit error message to the compressor
> [RFC3544]."

Thanks!

Spencer

> Hi, Cullen,
>
> Jerry's proposed text is exactly what I was thinking of (but did not have 
> the background to suggest, of course). If you agree, I think it's the 
> right thing to do.
(Continue reading)

Scott W Brim | 2 Mar 13:26 2007

review of draft-kunze-rfc2413bis-05.txt

No objection.

This is an update of the RFC describing the Dublin Core, which has
been documented by ANSI Z39 for years.  The only possible tweaks would
be in the element descriptions and references.  Ted Hardie apparently
already covered them in his comments.  I didn't see anything further.

I sent this just to gen-art because I have little to say on an IETF
last call for an informational RFC updating a previous one.
Elwyn Davies | 2 Mar 18:33 2007

Gen-art last call review of draft-zeilenga-ldap-entrydn-01

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-zeilenga-ldap-entrydn-01
Reviewer: Elwyn Davies
Review Date: 2 March 2007
IETF LC End Date: 30 March 2007
IESG Telechat date: (if known) -

Summary:
Ready for proposed standard.

Editorial nits if you are revising:

idnits warns that the RFC2119 language isn't actually used.

s1, para 4: s/Search filters above is described using/The example search filter shown in the previous
paragraph specifies the components to be matched using/
s1, para 4: s/'componetFilterMatch'/'componentFilterMatch'/

s4.1: The first sentence is not good English. 

's5.4'?  Should this be 4.2?  If so the following sections need renumbering. Also the first sentence needs
fixing up in the same way as s4.1. 
Black_David | 2 Mar 22:47 2007

Gen ART review of IS-IS Link Attribute draft

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-isis-link-attr-03.txt
Reviewer: David Black
Review Date: 2 March 2007
IETF LC End Date: 12 March 2007

Summary:
This draft is basically ready for publication, but has nits
that should be fixed before publication.

Comments:

This is a short draft that defines a link attributes extension
to IS-IS plus the first two attributes that it carries.  One has
to be an IS-IS expert to fully understand this draft - that's
quite reasonable for this sort of draft.

The Abstract should say that TLV 22 is the extended IS
reachability TLV.

idnits 2.03.11 finds the downref noted in the Last Call, flags
[IS-IS] as a possible downref (as an ISO standard it's definitely
not a downref), and says that page 4 has 59 lines (vs. 58 max).

(Continue reading)

Pasi.Eronen | 5 Mar 12:13 2007
Picon

Gen-ART review of draft-ietf-ccamp-crankback-06


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-ccamp-crankback-06
Reviewer: Pasi Eronen
Review Date: 05 March 2007
IESG Telechat date: 08 March 2007

Summary:

This draft is ready for publication as a Proposed Standard RFC.

Comments:

This document assumes a fair amount of background knowledge
that I don't have, so I don't really understand most of the
technical details. But generally, the document looks OK 
and I found nothing to complain about except some idnits:

Missing Reference: 'RC3473' is mentioned on line 202, but not defined
Missing Reference: 'RFC4373' is mentioned on line 537, but not defined
Missing Reference: 'RFC4201' is mentioned on line 918, but not defined
Unused Reference: 'G8080' is defined on line 1500, but not referenced

Best regards,
(Continue reading)

Elwyn Davies | 5 Mar 13:16 2007

Gen-art review of draft-ietf-webdav-rfc2518bis-18.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 wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-ietf-webdav-rfc2518bis-18.txt
Reviewer: Elwyn Davies
Review Date: 05/03/2007
IESG Telechat date: 8 March 2007

Summary:
All my significant issues with -17 have been fixed in -18, and I believe this is 
   ready to go for PS.

There are a couple of residual consistency points that can be cleaned up in RFC 
Editing - see below.  The 'allprop' one is significant and needs fixing IMO.

Comments:

Treatment of 'allprop':  Appendix F.1 is now consistent with s9.1 regarding 
which properties are returned by 'allprop', but the wording of the definition in 
s14.2 is still inconsistent in that it does not mention properties defined in 
other documents.  I think that s14.2 should also make a requirement that 'other 
documents' explicitly say whether a property is to be returned with 'allprop'. 
The examples in 9.1.5 and s9.1.6 also fail to state the possibility of returning 
properties defined in other documents - I suggested that the example in s9.1.6 
could be used to illustrate this.

(Continue reading)

Miguel Garcia | 5 Mar 13:42 2007
Picon

Gen-ART review of draft-ietf-pce-pcecp-interarea-reqs-05.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 wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-ietf-pce-pcecp-interarea-reqs-05.txt
Reviewer: Miguel Garcia <miguel.an.garcia <at> nokia.com>
Review Date: 2007-03-05
IESG Telechat date: 08 March 2007

Summary: The document is ready for publication as Informational RFC.

Comments: I have only a very subjective comment. In my opinion 
requirements drafts should make an abstraction of the solution and just 
note down the requirements. However, while reading this draft, I got the 
impression that the authors have been thinking quite a lot on the 
solution space, haven't separated them from the solution, and have 
written down a few solutions. Just to illustrate a couple of examples. 
On Section 4.8 the text reads:

    The request message MUST allow for the inclusion of the address of
    the originating PCC.

This is a solution for a requirement. Unfortunately it is not clear to 
me what the requirement is. It is probably something related to the 
"ability of a PCE to apply PCC-specific policies" or something like 
that, where a solution is "to record the address of the PCC in request 
messages, so that the PCE can apply a pcc-specific policy".
(Continue reading)


Gmane