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

2019-02-12 Thread 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

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

2018-12-17 Thread Acee Lindem (acee) 
Hi Padma, 
Is the updated draft coming soon? 
Thanks,
Acee 

On 11/28/18, 2:31 PM, "Padmadevi Pillay Esnault"  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"  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.]

...
11H-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

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

2018-11-28 Thread Padmadevi Pillay Esnault 
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"  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.]

...
11H-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 derivative works of it may
65   not be created outside the IETF Standards Process, except to format
66   it for publication as an RFC or to translate it into languages other
67   than English.

[major] As far as I can tell, the first version of
draft-keyupate-ospf-ospfv2-hbit (the

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

2018-11-28 Thread Alvaro Retana 
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.]


11H-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 derivative works of it may
65   not be created outside the IETF Standards Process, except to format
66   it for publication as an RFC or to translate it into languages other
67   than English.

[major] As far as I can tell, the first version of
draft-keyupate-ospf-ospfv2-hbit (the predecessor of this document) was
published in 2015.  So the copyright text above doesn't apply.  Are we
missing other predecessors?

If not, then this issue should be easy to fix.  In at least the XML editor
that I use, there's an option to indicate pre-RFC5378 work, or not.  In
this case it seems like it should be No.



85 1.  Introduction

[minor] Same comment as for the Abstract: describing the functionality in
terms of OSPFv2 would have been nicer.  You can still make the reference to
the R-bit at the end, if you really want to.

87   OSPFv3 [RFC5340]