Subject: [Gen-art] A *new* batch of IETF LC reviews - 4 July 2008

From: "Mary Barnes" <[email-masked]>
Date: Sat, 5 Jul 2008 21:06:15 -0500

Hi all,

Sorry for the delay - I could not get to my "temp-dir" last nite.

Here's the link to the new LC assignments for this week:
http://www.softarmor.com/rai/temp-gen-art/reviewers-080704-lc.html

The assignments are captured in the spreadsheets: 
http://www.softarmor.com/rai/temp-gen-art/gen-art.html 
http://www.softarmor.com/rai/temp-gen-art/gen-art-by-reviewer.html 

The standard template is included below.

Thanks, 
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 resolve these comments along with any other Last Call comments
you may receive.

Document: 
Reviewer: 
Review Date:  
IETF LC End Date: 
IESG Telechat date: (if known)

Summary:

Comments:

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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 07 Jul 2008 15:35:02 -0400

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-ccamp-ospf-interas-te-extensions-05.txt
	OSPF Extensions in Support of Inter-AS Multiprotocol Label
		Switching (MPLS) and Generalized MPLS (GMPLS)
		Traffic Engineering
Reviewer: Joel M. Halpern
Review Date: 7-July-2008
IETF LC End Date: 14-July-2008
IESG Telechat date: N / A

Summary:  This document appears ready for publication as a Proposed 
Standard.  When other document editing is being done, the minor comments 
below should be considered.

Minor Comments:
1)  It took me three readings to realize what the last sentence of the 
Abstract was trying to tell me.  Would it be accurate to replace
     "No support for flooding TE information from outside the AS is 
proposed or defined in this document."
with
     "No support for flooding information from within one AS to another 
AS is proposed or defined in this document."
     The reason I ask is that what the document is about is flooding 
information about inter-AS links.  Such links are actually outside of 
the AS, and so the current phrasing is slightly confusing.
     As a less informative, but still meaningful last sentence if the 
above does not work, would adding the following before the existing 
sentence work for you?:
     "All information described in this document is originated by the 
site AS Border Router (ASBR)."

2) It is probably the correct decision to carry the AS number of 
neighbors in this mechanism, rather than relying on other protocols 
which may or may not have such information.  I would suggest adding a 
note to the introductory material in section 3 making this point.  The 
text should simply say something like "while some of this information 
may be available within the AS from other protocols, in order to avoid 
any dependency on where such protocols are processed, this mechanism 
carries all the information needed for the required TE operations."

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 07 Jul 2008 15:43:43 -0400

Document: draft-ietf-ccamp-isis-interas-te-extension-02.txt
	ISIS Extensions in Support of Inter-AS Multiprotocol Label
		Switching (MPLS) and Generalized MPLS (GMPLS)
		Traffic Engineering
Reviewer: Joel M. Halpern
Review Date: 7-July-2008
IETF LC End Date: 14-July-2008
IESG Telechat date: N / A

Minor Comments:
1)  (comment on abstract based on problem found when reading OSPF document.)
The last sentence of the Abstract is somewhat confusing.  Would it be 
accurate to replace

3) Is there a reason that the OSPF and ISIS document differ as to the 
strength of recommending a specific setting of the flooding scope?  The 
OSPF documents say that it SHOULD be area specific.  The ISIS document 
merely describes the two settings (level specific and inter-layer 
flooding allowed) without making either one a SHOULD.

---

From: Mach Chen <[email-masked]>
Date: Tue, 08 Jul 2008 10:27:36 +0800

Hi Joel,

Thanks for your useful comments!

We will resolve your comments along with other last call comments.

Best regards,
Mach

--------------------------------------------------
From: "Joel M. Halpern" <[email-masked]>
Sent: Tuesday, July 08, 2008 3:35 AM
To: "Mary Barnes" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>; 
<[email-masked]>; "Ross Callon" <[email-masked]>
Subject: Re: [Gen-art] LC review: 
draft-ietf-ccamp-ospf-interas-te-extensions-05.txt

>     "No support for flooding information from within one AS to another AS 
> is proposed or defined in this document."

OK.

> information about inter-AS links.  Such links are actually outside of the 
> AS, and so the current phrasing is slightly confusing.
>     As a less informative, but still meaningful last sentence if the above 
> does not work, would adding the following before the existing sentence 
> work for you?:
>     "All information described in this document is originated by the site 
> AS Border Router (ASBR)."
>
> 2) It is probably the correct decision to carry the AS number of neighbors 
> in this mechanism, rather than relying on other protocols which may or may 
> not have such information.  I would suggest adding a note to the 
> introductory material in section 3 making this point.  The text should 
> simply say something like "while some of this information may be available 
> within the AS from other protocols, in order to avoid any dependency on 
> where such protocols are processed, this mechanism carries all the 
> information needed for the required TE operations."

OK, I will add the suggested text into the next revision.

---

From: Mach Chen <[email-masked]>
Date: Tue, 08 Jul 2008 11:05:05 +0800

Hi Joel,

I will resolve the comments along with other LC comments after the LC.

Pls see inline.

Best regards,
Mach

--------------------------------------------------
From: "Joel M. Halpern" <[email-masked]>
Sent: Tuesday, July 08, 2008 3:43 AM
To: "Mary Barnes" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>; 
<[email-masked]>; "Ross Callon" <[email-masked]>
Subject: Re: [Gen-art] LC review: 
draft-ietf-ccamp-isis-interas-te-extension-02.txt

> AS is proposed or defined in this document."

OK, accept.

> carries all the information needed for the required TE operations."

OK, your suggested text will be added into the next revision after LC .
> merely describes the two settings (level specific and inter-layer flooding 
> allowed) without making either one a SHOULD.

No, the flooding scope recommended in two drafts is the same, that is the 
flooding scope could be either area or AS specific, the choice between the 
use of area and AS flooding scope is a network-wide policy choice.

How about we add the following sentence into the section 3.1 before the 
sentence "The choice between..." of the ISIS draft:

"The flooding-scope bit SHOULD be set 0 if the flooding scope is to be 
limited to within the single IGP area to which the ASBR belongs, or MAY be 
set to 1 if the information is intended to reach all routers (including area 
border routers, ASBRs, and PCEs) in the entire ISIS routing domain."