Subject: [Gen-art] Gen-ART review of draft-ietf-idr-rfc3065bis-05.txt

From: Harald Alvestrand <[email-masked]>
Date: Wed, 16 Aug 2006 01:30:14 -0700

I am the assigned Gen-ART reviewer for this document. For background
on Gen-ART, please see the FAQ at:

	http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html

Please consider these comments along with any other last call comments you 
may receive.

Document: draft-ietf-idr-rfc3065bis-05.txt
          (along with draft-mcpherson-idr-rfc3065bis-impl-00)
Intended status: Draft
Reviewer: Harald Alvestrand
Date: August 16, 2006
Summary: Ready, has nits

This draft is going for Draft Standard. The implementation report (which is an expired internet-draft, but also stored in the implementation repository; http://www.ietf.org/IESG/Implementations/implem_RFC3065bis.txt) is also reviewed here.

Basically, I think this is ready.

Nits:

- The document has no "changes from RFC 3065" section. The introduction has a paragraph outlining the changes, but does not specify exactly what the protocol-impacting changes (if any) are. For implementors attempting to upgrade their implementation to conformance with the new document, such a section would be very helpful.

- Protocol puzzlement: As far as I can see, this protocol extension defines the AS_CONFED_SET segment type, and specifies when it needs to be removed from an AS_PATH, but never specifies a condition under which an AS_CONFED_SET is inserted. If that's correct, adding the phrase "not used now, reserved for future extension" to the definition in section 3 would be helpful.

- Supernitty nit: In section 7, the sentence

   Additionally, confederations (as well as route reflectors), by
   excluding different reachability information from consideration at
   different locations in a confederation, have been shown [RFC 3365]
   cause permanent oscillation between candidate routes when using the
   tie breaking rules required by BGP [BGP-4].

is missing the word "to" before the word "cause" in the next-to-last line.....

Implementation report nits:

- It refers to BGP-4 as "work in progress". Should be updated to existing BGP spec.
- The document is unclear on whether it's an implementation report for rfc3065bis (in header) or RFC 3065 (in normative references). It should decide one way or the other - not that I think it matters, given the apparent lack of technical changes.

IDNits output:

idnits 1.105 

tmp/draft-ietf-idr-rfc3065bis-05.txt:

  Checking nits according to http://www.ietf.org/ID-Checklist.html:
  * The document seems to lack an IANA Considerations section.
    
    Checking conformance with RFC 3978/3979 boilerplate...

  * Found RFC 3978 Section 5.4 paragraph 1 boilerplate (on line 519), which
    is fine, but *also* found RFC 2026 Section 10.4C paragraph 1 boilerplate
    on line 36. It should be removed.
  * There are 3 instances of too long lines in the document, the longest one
    being 1 character in excess of 72.

  Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt:
    Nothing found here (but these checks do not cover all of
    1id-guidelines.txt yet).

  Miscellaneous warnings:
  - Line 332 has weird spacing: '... system  withi...'
  - The document seems to lack the recommended RFC 2119 boilerplate, even if
    it appears to use RFC 2119 keywords. 
    (The document does seem to have the reference to RFC 2119 which the
    ID-Checklist requires).

  Experimental warnings:
  - Unused Reference: 'RFC 1771' is defined on line 443, but not referenced
  - Unused Reference: 'RFC 1863' is defined on line 446, but not referenced
  - Unused Reference: 'RFC 2119' is defined on line 449, but not referenced

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

---

From: Danny McPherson <[email-masked]>
Date: Sun, 20 Aug 2006 08:53:46 -0600

On Aug 16, 2006, at 2:30 AM, Harald Alvestrand wrote:

> Please consider these comments along with any other last call  
> comments you may receive.
>
> This draft is going for Draft Standard. The implementation report  
> (which is an expired internet-draft, but also stored in the  
> implementation repository; http://www.ietf.org/IESG/Implementations/ 
> implem_RFC3065bis.txt) is also reviewed here.
>

Harald,
Good feedback, thanks.  I'll add a complete "changes from previous  
rev/3065"
section, as there were a few noteworthy for the implementer.  I'm  
still working
with John on what to do with AS_CONFED_SET - more to follow there.  I'll
fix the nits below as well.

Good feedback from the GEN-ART team, many thanks!

-danny

>
> Nits:
>
> - The document has no "changes from RFC 3065" section. The  
> introduction has a paragraph outlining the changes, but does not  
> specify exactly what the protocol-impacting changes (if any) are.  
> For implementors attempting to upgrade their implementation to  
> conformance with the new document, such a section would be very  
> helpful.
>
> - Protocol puzzlement: As far as I can see, this protocol extension  
> defines the AS_CONFED_SET segment type, and specifies when it needs  
> to be removed from an AS_PATH, but never specifies a condition  
> under which an AS_CONFED_SET is inserted. If that's correct, adding  
> the phrase "not used now, reserved for future extension" to the  
> definition in section 3 would be helpful.
>
> - The document is unclear on whether it's an implementation report  
> for rfc3065bis (in header) or RFC 3065 (in normative references).  
> It should decide one way or the other - not that I think it  
> matters, given the apparent lack of technical changes.
>
> IDNits output:
>
> idnits 1.105
>    it appears to use RFC 2119 keywords.    (The document does seem  
> to have the reference to RFC 2119 which the
>    ID-Checklist requires).
>
>  Experimental warnings: