Subject: [OSPF] FW: New Version Notification for draft-ietf-ospf-prefix-link-attr-01.txt

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 9 Sep 2014 00:29:01 +0000

This version includes clarifications in response to Tony Przygienda¹s
comments as well as some editorial changes. There are no changes to the
protocol extensions.

Thanks,
Acee 

On 9/8/14, 2:27 PM, "[email-masked]" <[email-masked]>
wrote:

>
>A new version of I-D, draft-ietf-ospf-prefix-link-attr-01.txt
>has been successfully submitted by Acee Lindem and posted to the
>IETF repository.
>
>Name:		draft-ietf-ospf-prefix-link-attr
>Revision:	01
>Title:		OSPFv2 Prefix/Link Attribute Advertisement
>Document date:	2014-09-08
>Group:		ospf
>Pages:		14
>URL:            
>http://www.ietf.org/internet-drafts/draft-ietf-ospf-prefix-link-attr-01.tx
>t
>Status:         
>https://datatracker.ietf.org/doc/draft-ietf-ospf-prefix-link-attr/
>Htmlized:       
>http://tools.ietf.org/html/draft-ietf-ospf-prefix-link-attr-01
>Diff:           
>http://www.ietf.org/rfcdiff?url2=draft-ietf-ospf-prefix-link-attr-01
>
>Abstract:
>   OSPFv2 requires functional extension beyond what can readily be done
>   with the fixed-format Link State Advertisements (LSAs) as described
>   in RFC 2328.  This document defines OSPF opaque LSAs based on Type-
>   Length-Value (TLV) tuples that can be used to associate additional
>   attributes with prefixes or links.  Dependent on the application,
>   these prefixes and links may or not be advertised in the fixed-format
>   LSAs.  The OSPF opaque LSAs are optional and fully backward
>   compatible.
>
>                  
>        
>
>
>Please note that it may take a couple of minutes from the time of
>submission
>until the htmlized version and diff are available at tools.ietf.org.
>
>The IETF Secretariat
>

---

From: prz <[email-masked]>
Date: Mon, 08 Sep 2014 17:57:56 -0700

>>has been successfully submitted by Acee Lindem and posted to the

 nit:

 :  these prefixes and links may or not be

 suggest to replace with

  these prefixes and links may or _may_ not be

 Otherwise, yepp, I like the changes, they do not prescribe how to deal
 with specific duplicates too tightly but tight enough such as
 mandating the drafts hinging off this
 draft to deal with the anomalies. the coupling of opaque flooding scope
 with prefix flooding scope is nicely done, it basically says 
 application must
 make sure it floods @ correct scope but not preventing putting 
 different
 types @ same flooding scope into same opaque.

 I think all my concerns have been addressed pretty nicely.

 --- tony

>>Abstract