Subject: [Gen-art] Gen-ART Review of draft-ietf-ospf-ospfv3-update-18

From: Christian Vogt <[email-masked]>
Date: Thu, 10 Apr 2008 13:05:01 +0300

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-ospf-ospfv3-update-18.txt
Reviewer:  Christian Vogt
Review Date:  April 10, 2008

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

Comments:

This document specifies OSPF for IPv6 networks.  It is very well
written, clear overall, structured, and easily understandable.  I
suggest this document to move forward in the publication process.
Few comments that should be addressed on this way:

(1)  The document, in particular abstract and introduction, is
      ambiguous on whether (a) it describes extensions/modifications
      to OSPF for IPv6 support, which would result in an OSPF version
      for both IPv4 and IPv6, or whether (b) it is a separate OSPF
      version specifically for IPv6.  The first sentence of the
      abstract implies (a).  But later the abstract implies (b),
      because it says that authentication mechanisms have been replaced
      by IPv6-specific ones, leaving no authentications means for IPv4.
      Then again, the increment of the OSPF version number specified in
      section 2.7 indicates that (a) is the case.  Please clarify the
      purpose and content of the document early in the abstract and
      introduction.

(2)  The document is very consistent WRT to introducing all acronyms
      (by spelling them out) when they appear first.  Do this for "LSA"
      also.  See 2nd paragraph of abstract.

(3)  In section 2.5, a special source address selection rule is
      defined for virtual links.  Is this rule needed specifically for
      OSPF, or is it specific to virtual links?  If the latter was the
      case, would it make sense to define this rule more generally in an
      IPv6 document?

Good luck with the publication,
- Christian

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

---

From: Acee Lindem <[email-masked]>
Date: Mon, 14 Apr 2008 12:38:36 -0400

Hi Christian,
Thanks taking the time to review this large document. See inline.

>      purpose and content of the document early in the abstract and

As you surmised, it is (a). I'll make sure this is clear.

>      also.  See 2nd paragraph of abstract.

I added a bunch of these. I'll make sure I get this one and I'll  
check for other acronyms that require expansion.

>      case, would it make sense to define this rule more generally  

I'd have to say this rule is specific to OSPFv3 virtual links. I  
think the meaning of "virtual link" varies depending on the context  
so I wouldn't try and define behavior beyond OSPFv3. For example, in  
one context a "virtual link" might imply a tunnel while it the OSPFv3  
sense it is a multi-hop adjacency implying any OSPF path through the  
transit area can be used for backbone routing.

Thanks,
Acee

---

From: Christian Vogt <[email-masked]>
Date: Mon, 14 Apr 2008 22:38:38 +0300

Hi Acee,

thanks for addressing these comments.  Your explanation regarding  
virtual links is convincing, so the corresponding text should be left  
as is in the document.

Take care,
- Christian

On Apr 14, 2008, at 19:38, Acee Lindem wrote:
> so I wouldn't try and define behavior beyond OSPFv3. For example,  
> in one context a "virtual link" might imply a tunnel while it the  
> OSPFv3 sense it is a multi-hop adjacency implying any OSPF path  
> through the transit area can be used for backbone routing.
>
> Thanks,
> Acee
>
>
>
>>

---

From: Acee Lindem <[email-masked]>
Date: Tue, 15 Apr 2008 14:59:28 -0400

Hi Christian,
Actually, I misstated the intent of the document below. OSPFv3  
requires IPv6 and is specifically designed to over it. It can be  
extended to advertise reachability information for other address  
families (e.g., IPv4) as well and there is more than one draft  
stating how this should be done. However, this is not fully specified  
in this document. I've attempted to clarify this by including the  
version numbers in the first reference in the abstract and introduction.

http://www.ietf.org/internet-drafts/draft-ietf-ospf-ospfv3-update-21.txt

Thanks,
Acee

On Apr 14, 2008, at 3:38 PM, Christian Vogt wrote:

> virtual links is convincing, so the corresponding text should be  
> left as is in the document.
>
> Take care,
> - Christian
>
>
>
>> think the meaning of "virtual link" varies depending on the  
>> context so I wouldn't try and define behavior beyond OSPFv3. For  
>> example, in one context a "virtual link" might imply a tunnel  
>> while it the OSPFv3 sense it is a multi-hop adjacency implying any  
>> OSPF path through the transit area can be used for backbone routing.
>>
>> Thanks,
>> Acee
>>
>>
>>
>>>