Re: [Lsr] IPR Poll on "OSPF Extension for Prefix Originator" - draft-wang-lsr-ospf-prefix-originator-ext-01

[Dongjie (Jimmy)]

Hi Acee,

I'm not aware of any IPR other than the one referenced below.

Best regards,
Jie
发件人：Acee Lindem (acee) 
收件人：Aijun Wang 
;draft-wang-lsr-ospf-prefix-originator-...@ietf.org 

抄 送：lsr@ietf.org 
时间：2019-02-13 10:07:46
主 题：Re: 答复: [Lsr] IPR Poll on "OSPF Extension for Prefix Originator" - 
draft-wang-lsr-ospf-prefix-originator-ext-01

Speaking as a co-author,
This IPR referenced below is the only one I’m aware of as well.
Thanks,
Acee

From: Aijun Wang 
Date: Tuesday, February 12, 2019 at 8:48 PM
To: Acee Lindem , 
"draft-wang-lsr-ospf-prefix-originator-...@ietf.org" 

Cc: "lsr@ietf.org" 
Subject: 答复: [Lsr] IPR Poll on "OSPF Extension for Prefix Originator" - 
draft-wang-lsr-ospf-prefix-originator-ext-01

Hi, Acee:

Apart from the IPR declared in https://datatracker.ietf.org/ipr/3420/ , I am 
not aware of any other IPR.
Thanks for your efforts.


Best Regards.

Aijun Wang
Network R and Operation Support Department
China Telecom Corporation Limited Beijing Research Institute,Beijing, China.
发件人: Acee Lindem (acee) [mailto:a...@cisco.com]
发送时间: 2019年2月9日 1:01
收件人: draft-wang-lsr-ospf-prefix-originator-...@ietf.org
抄送: lsr@ietf.org
主题: [Lsr] IPR Poll on "OSPF Extension for Prefix Originator" - 
draft-wang-lsr-ospf-prefix-originator-ext-01

Authors,

In preparation for a WG adoption call:

Are you aware of any IPR relating to 
https://datatracker.ietf.org/doc/draft-wang-lsr-ospf-prefix-originator-ext? If 
so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 
3979, 4879, 3669 and 5378 for more details). If you are listed as a document 
author or contributor please respond to this email regardless of whether or not 
you are aware of any relevant IPR. *The response needs to be sent to the LSR WG 
mailing list.* The document will not advance to the next stage until a response 
has been received from each author and contributor. If you are on the LSR WG 
email list but are not listed as an author or contributor, then please 
explicitly respond only if you are aware of any IPR that has not yet been 
disclosed in conformance with IETF rules.

Thanks,
Acee


___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] 答复: IPR Poll on "OSPF Extension for Prefix Originator" - draft-wang-lsr-ospf-prefix-originator-ext-01

[Acee Lindem (acee)]

Speaking as a co-author,
This IPR referenced below is the only one I’m aware of as well.
Thanks,
Acee

From: Aijun Wang 
Date: Tuesday, February 12, 2019 at 8:48 PM
To: Acee Lindem , 
"draft-wang-lsr-ospf-prefix-originator-...@ietf.org" 

Cc: "lsr@ietf.org" 
Subject: 答复: [Lsr] IPR Poll on "OSPF Extension for Prefix Originator" - 
draft-wang-lsr-ospf-prefix-originator-ext-01

Hi, Acee:

Apart from the IPR declared in https://datatracker.ietf.org/ipr/3420/ , I am 
not aware of any other IPR.
Thanks for your efforts.


Best Regards.

Aijun Wang
Network R and Operation Support Department
China Telecom Corporation Limited Beijing Research Institute,Beijing, China.
发件人: Acee Lindem (acee) [mailto:a...@cisco.com]
发送时间: 2019年2月9日 1:01
收件人: draft-wang-lsr-ospf-prefix-originator-...@ietf.org
抄送: lsr@ietf.org
主题: [Lsr] IPR Poll on "OSPF Extension for Prefix Originator" - 
draft-wang-lsr-ospf-prefix-originator-ext-01

Authors,

In preparation for a WG adoption call:

Are you aware of any IPR relating to 
https://datatracker.ietf.org/doc/draft-wang-lsr-ospf-prefix-originator-ext? If 
so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 
3979, 4879, 3669 and 5378 for more details). If you are listed as a document 
author or contributor please respond to this email regardless of whether or not 
you are aware of any relevant IPR. *The response needs to be sent to the LSR WG 
mailing list.* The document will not advance to the next stage until a response 
has been received from each author and contributor. If you are on the LSR WG 
email list but are not listed as an author or contributor, then please 
explicitly respond only if you are aware of any IPR that has not yet been 
disclosed in conformance with IETF rules.

Thanks,
Acee


___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

[Lsr] 答复: IPR Poll on "OSPF Extension for Prefix Originator" - draft-wang-lsr-ospf-prefix-originator-ext-01

[Aijun Wang]

Hi, Acee:

 

Apart from the IPR declared in https://datatracker.ietf.org/ipr/3420/ , I am 
not aware of any other IPR.

Thanks for your efforts.

 

 

Best Regards.

 

Aijun Wang

Network R and Operation Support Department

China Telecom Corporation Limited Beijing Research Institute,Beijing, China.

发件人: Acee Lindem (acee) [mailto:a...@cisco.com] 
发送时间: 2019年2月9日 1:01
收件人: draft-wang-lsr-ospf-prefix-originator-...@ietf.org
抄送: lsr@ietf.org
主题: [Lsr] IPR Poll on "OSPF Extension for Prefix Originator" - 
draft-wang-lsr-ospf-prefix-originator-ext-01

 

Authors, 

 

In preparation for a WG adoption call:

 

Are you aware of any IPR relating to 
https://datatracker.ietf.org/doc/draft-wang-lsr-ospf-prefix-originator-ext? If 
so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 
3979, 4879, 3669 and 5378 for more details). If you are listed as a document 
author or contributor please respond to this email regardless of whether or not 
you are aware of any relevant IPR. *The response needs to be sent to the LSR WG 
mailing list.* The document will not advance to the next stage until a response 
has been received from each author and contributor. If you are on the LSR WG 
email list but are not listed as an author or contributor, then please 
explicitly respond only if you are aware of any IPR that has not yet been 
disclosed in conformance with IETF rules.

 

Thanks,
Acee

 

 

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] AD Review of draft-ietf-ospf-ospfv2-hbit-06

[Keyur Patel]

Hi Alvaro,

Apologies for the delay. We will go thru the comments and get back to you.

Regards,
Keyur

From: Alvaro Retana 
Date: Tuesday, February 12, 2019 at 1:26 PM
To: Padmadevi Pillay Esnault , 
"draft-ietf-ospf-ospfv2-h...@ietf.org" 
Cc: Yingzhen Qu , "lsr@ietf.org" , 
"lsr-cha...@ietf.org" , "Acee Lindem (acee)" 

Subject: Re: AD Review of draft-ietf-ospf-ospfv2-hbit-06
Resent-From: 
Resent-To: , , , 

Resent-Date: Tuesday, February 12, 2019 at 1:26 PM

Ping!

Any progress on this document?

Thanks!

Alvaro.


On December 17, 2018 at 8:22:25 AM, Acee Lindem (acee) 
(a...@cisco.com) wrote:
Hi Padma,
Is the updated draft coming soon?
Thanks,
Acee

On 11/28/18, 2:31 PM, "Padmadevi Pillay Esnault" 
mailto:pa...@huawei.com>> wrote:

Dear Alvaro

Thank you for your review.

We will go through the comments and work on them.

Thanks
Padma on behalf of my co-authors

On 11/28/18, 7:53 AM, "Alvaro Retana" 
mailto:aretana.i...@gmail.com>> wrote:

Dear authors:

I just finished reading this document. Even though it is relatively short,
I have significant concerns and I think it needs more work. Please take a
look at the detailed comments in-line below -- I'm highlighting some of the
issues here.

(1) What is the Update to rfc2328? Please be specific in both the Abstract
and the Introduction to indicate how rfc2328 is Updated. Also, see my
question about rfc6987 in §6.

(2) Operational/Deployment Considerations. There are several places
(specially in §3) where the specification offers a choice (e.g. by using
MAY). Some of those choices would be better informed if there was a
discussion of the considerations behind them. Please take a look at
rfc5706 (specially §2). Either a discussion close to where the behavior is
specified or a separate section is ok. Please also keep migration in mind
(see comments in §5).

(3) Both the IANA and Security Considerations sections need more details.


I will wait for them to be addressed before starting the IETF Last Call.

Thanks!

Alvaro.


[The line numbers come from idnits.]

...
11 H-bit Support for OSPFv2
12 draft-ietf-ospf-ospfv2-hbit-06

[nit] Please make the title more descriptive. "non-transit router", "host
mode", etc. come to mind.


14 Abstract

16 OSPFv3 defines an option bit for router-LSAs known as the R-bit in
17 RFC5340. If the R-bit is clear, an OSPFv3 router can participate in
18 OSPF topology flooding, however it will not be used as a transit
19 router. In such cases, other routers in the OSPFv3 routing domain
20 only install routes to allow local traffic delivery. This document
21 defines the H-bit functionality to prevent other OSPFv2 routers from
22 using the router for transit traffic in OSPFv2 routing domains as
23 described in RFC 2328. This document updates RFC 2328.

[minor] Describing the functionality in terms of OSPFv2 would have been
nice. IOW, there's no need (in the Abstract) to force the reader to go
figure out what OSPFv3 already did to decide if it's worth reading this
document or not.

[major] What is the Update to rfc2328? Please be specific, both here and
in the Introduction: don't just mention the section updated, but (more
important) what is the update about. "This document updates rfc2328 by
assigning a bit...changing the SPF process...creating a registry..."
All/none/something else?

Note that the answer to "what is the update?" doesn't have to be all. I
think that the registry creation is a must. But Updating because of the
SPF changes means that you expect an rfc2328 implementation to consider the
H-bit when running SPF. I think you really mean that implementations of
this document (i.e. not all rfc2328 implementations) have to use the
modified SPF. That is my guess...please consider the answer carefully.


...
42 Copyright Notice

44 Copyright (c) 2018 IETF Trust and the persons identified as the
45 document authors. All rights reserved.

47 This document is subject to BCP 78 and the IETF Trust's Legal
48 Provisions Relating to IETF Documents
49 (https://trustee.ietf.org/license-info) in effect on the date of
50 publication of this document. Please review these documents
51 carefully, as they describe your rights and restrictions with respect
52 to this document. Code Components extracted from this document must
53 include Simplified BSD License text as described in Section 4.e of
54 the Trust Legal Provisions and are provided without warranty as
55 described in the Simplified BSD License.

57 This document may contain material from IETF Documents or IETF
58 Contributions published or made publicly available before November
59 10, 2008. The person(s) controlling the copyright in some of this
60 material may not have granted the IETF Trust the right to allow
61 modifications of such material outside the IETF Standards Process.
62 Without obtaining an adequate license from the person(s) controlling
63 the copyright in such materials, this document may not be modified
64 outside the IETF Standards Process, and 

[Lsr] lsr - Update to a Meeting Session Request for IETF 104

[IETF Meeting Session Request Tool]

An update to a meeting session request has just been submitted by Liz Flynn, on 
behalf of the lsr working group.


-
Working Group Name: Link State Routing
Area Name: Routing Area
Session Requester: Liz Flynn

Number of Sessions: 2
Length of Session(s):  2 Hours, 1.5 Hours
Number of Attendees: 100
Conflicts to Avoid: 
 First Priority: lsvr ipsecme idr rtgwg
 Second Priority: netmod rift
 Third Priority: bess bier


People who must be present:
  Acee Lindem
  Christian Hopps
  Alvaro Retana

Resources Requested:

Special Requests:
  
-

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr