Re: [OSPF] Gen-ART Review of draft-ietf-ospf-ospfv3-update-18

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:

> 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:
>> Hi Christian,
>> Thanks taking the time to review this large document. See inline.
>>
>> On Apr 10, 2008, at 6:05 AM, Christian Vogt wrote:
>>
>>> 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.
>>
>> As you surmised, it is (a). I'll make sure this is clear.
>>
>>
>>>
>>> (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.
>>
>> I added a bunch of these. I'll make sure I get this one and I'll  
>> check for other acronyms that require expansion.
>>
>>>
>>> (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?
>>
>> 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
>>
>>
>>
>>>
>>> Good luck with the publication,
>>> - Christian
>>>
>>>
>>
>>
>