Re: [Lsr] [Gen-art] Genart last call review of draft-ietf-isis-yang-isis-cfg-37

[Alissa Cooper]

Stewart, thanks for your review. Acee, thanks for your response. I entered a No 
Objection ballot.

Alissa


> On Sep 20, 2019, at 3:22 PM, Acee Lindem (acee)  wrote:
> 
> Thanks Stewart - we will fix this nit in the -38 version. 
> Acee
> 
> On 9/18/19, 10:14 AM, "Stewart Bryant via Datatracker"  
> wrote:
> 
>Reviewer: Stewart Bryant
>Review result: Ready
> 
>I am the assigned Gen-ART reviewer for this draft. The General Area
>Review Team (Gen-ART) reviews all IETF documents being processed
>by the IESG for the IETF Chair.  Please treat these comments just
>like any other last call comments.
> 
>For more information, please see the FAQ at
> 
>.
> 
>Document: draft-ietf-isis-yang-isis-cfg-??
>Reviewer: Stewart Bryant
>Review Date: 2019-09-18
>IETF LC End Date: 2019-09-23
>IESG Telechat date: Not scheduled for a telechat
> 
>Summary: A true magnum opus. Well written and from a GENART point of view 
> ready
>to be published. I have not checked the YANG syntax, and have only checked 
> that
>the configuration symantics look plausible. I assume that specalist YANG 
> and
>Routing reviewers will look at that detail.
> 
>Major issues: None
> 
>Minor issues: None
> 
>Nits/editorial comments:
>   This document defines a YANG data model that can be used to configure
>   and manage IS-IS protocol on network elements.
> 
>SB> s/manage/manage the/
> 
> 
> 
> ___
> Gen-art mailing list
> gen-...@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art

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

Re: [Lsr] WG Adoption poll for draft-acee-lsr-ospf-yang-augmentation-v1-01

[Acee Lindem (acee)]

Speaking as a co-author, I support this draft. When we froze the features in 
the base OSPF YANG model so it could be published, we committed to supporting 
new RFCs and drafts in separate model in a new draft.

I don't know of any IPR.
 
Thanks,
Acee

On 10/2/19, 5:29 PM, "Lsr on behalf of Christian Hopps"  wrote:

Hi Folks,

This begins a 2 week WG adoption poll for the following:

  https://datatracker.ietf.org/doc/draft-acee-lsr-ospf-yang-augmentation-v1/

Please send any comments to the list by Wednesday Oct 16th, 2019.

Thanks,
Chris.


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

Re: [Lsr] WG Adoption poll for draft-acee-lsr-ospf-yang-augmentation-v1-01

[Yingzhen Qu]

Speaking as co-author, I support the adoption of this draft. The modules are 
needed to support features that were not included in the base module.



I'm not aware of any IPR.



Thanks,

Yingzhen


From: Lsr  On Behalf Of Jeff Tantsura
Sent: Wednesday, October 02, 2019 3:14 PM
To: lsr@ietf.org; Christian Hopps 
Subject: Re: [Lsr] WG Adoption poll for 
draft-acee-lsr-ospf-yang-augmentation-v1-01

yes/support, missing pieces that need to be added

Cheers,
Jeff
On Oct 2, 2019, 2:28 PM -0700, Christian Hopps 
mailto:cho...@chopps.org>>, wrote:

Hi Folks,

This begins a 2 week WG adoption poll for the following:

https://datatracker.ietf.org/doc/draft-acee-lsr-ospf-yang-augmentation-v1/

Please send any comments to the list by Wednesday Oct 16th, 2019.

Thanks,
Chris.

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

Re: [Lsr] WG Adoption Poll for draft-acee-lsr-ospfv3-extended-lsa-yang-06

[Yingzhen Qu]

Speaking as co-author, I support the adoption of this draft.

I'm not aware of any IPR.

Thanks,
Yingzhen

-Original Message-
From: Lsr  On Behalf Of Acee Lindem (acee)
Sent: Wednesday, October 02, 2019 3:01 PM
To: Christian Hopps ; lsr@ietf.org
Subject: Re: [Lsr] WG Adoption Poll for 
draft-acee-lsr-ospfv3-extended-lsa-yang-06

Speaking as co-author, I support this draft. It is required for all OSPFv3 
extensions utilizing RFC8362 extended LSA encodings.
Additionally, I'm not aware of any IPR. 

Thanks,
Acee

On 10/2/19, 5:27 PM, "Lsr on behalf of Christian Hopps"  wrote:

Hi Folks,

This begins a 2 week WG adoption poll for the following:

  
https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-acee-lsr-ospfv3-extended-lsa-yang%2F&data=02%7C01%7Cyingzhen.qu%40futurewei.com%7Cb09e5a3e1861444abc1c08d7478425ac%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637056505241778999&sdata=%2B5DYemUUkUS7DjP8Em6l4bH4hC5mKITkllElDeMqImQ%3D&reserved=0

Please send any comments to the list by Wednesday Oct 16th, 2019.

Thanks,
Chris.


___
Lsr mailing list
Lsr@ietf.org
https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Flsr&data=02%7C01%7Cyingzhen.qu%40futurewei.com%7Cb09e5a3e1861444abc1c08d7478425ac%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637056505241778999&sdata=ar8%2B1fRU3ULbE9sBJ%2BSIcgiQcpvYId8ravEIfxzBWNU%3D&reserved=0
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

[Lsr] Adam Roach's No Objection on draft-ietf-isis-yang-isis-cfg-40: (with COMMENT)

[Adam Roach via Datatracker]

Adam Roach has entered the following ballot position for
draft-ietf-isis-yang-isis-cfg-40: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-isis-yang-isis-cfg/



--
COMMENT:
--


Thanks for the work that went into this model. I have only a handful
of minor issues I found when reading through the module.

---

>grouping spf-parameters {
>  container spf-control {
>  leaf paths {
>if-feature max-ecmp;
>type uint16 {
>  range "1..32";
>}

Why is this a uint16 rather than a uint8?

---

>  leaf-list tag {
>type uint32;
>description
>  "List of 32-bit tags associated with the IPv4 prefix.";
>  }
>  leaf-list tag64 {
>type uint64;
>description
>  "List of 32-bit tags associated with the IPv4 prefix.";
>  }

I think this second description is meant to say "64-bit" rather than "32-bit".

---

>  leaf reason {
>type string {
>  length "1..255";
>}
>description
>  "The system may provide a reason to reject the
>   adjacency. If the reason is not available,
>   an empty string will be returned.
>   The expected format is a single line text.";
>  }

This description is inconsistent with the definition: it calls for an empty
string, while the definition requires that at lest one character be present. If
you want to keep the description as-is, you need to adjust the length to be
"0..255". Alternately, you might indicate that the field is simply to be
omitted rather than empty, which appears to be the intention for other
"reason" fields in this model.


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

Re: [Lsr] WG Adoption poll for draft-acee-lsr-ospf-yang-augmentation-v1-01

[Jeff Tantsura]

yes/support, missing pieces that need to be added

Cheers,
Jeff
On Oct 2, 2019, 2:28 PM -0700, Christian Hopps , wrote:
> Hi Folks,
>
> This begins a 2 week WG adoption poll for the following:
>
> https://datatracker.ietf.org/doc/draft-acee-lsr-ospf-yang-augmentation-v1/
>
> Please send any comments to the list by Wednesday Oct 16th, 2019.
>
> Thanks,
> Chris.
>
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG Adoption Poll for draft-acee-lsr-ospfv3-extended-lsa-yang-06

[Jeff Tantsura]

yes/support

Cheers,
Jeff
On Oct 2, 2019, 2:27 PM -0700, Christian Hopps , wrote:
> Hi Folks,
>
> This begins a 2 week WG adoption poll for the following:
>
> https://datatracker.ietf.org/doc/draft-acee-lsr-ospfv3-extended-lsa-yang/
>
> Please send any comments to the list by Wednesday Oct 16th, 2019.
>
> Thanks,
> Chris.
>
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG Adoption Poll for draft-acee-lsr-ospfv3-extended-lsa-yang-06

[Acee Lindem (acee)]

Speaking as co-author, I support this draft. It is required for all OSPFv3 
extensions utilizing RFC8362 extended LSA encodings.
Additionally, I'm not aware of any IPR. 

Thanks,
Acee

On 10/2/19, 5:27 PM, "Lsr on behalf of Christian Hopps"  wrote:

Hi Folks,

This begins a 2 week WG adoption poll for the following:

  https://datatracker.ietf.org/doc/draft-acee-lsr-ospfv3-extended-lsa-yang/

Please send any comments to the list by Wednesday Oct 16th, 2019.

Thanks,
Chris.


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

[Lsr] The LSR WG has placed draft-acee-lsr-ospfv3-extended-lsa-yang in state "Call For Adoption By WG Issued"

[IETF Secretariat]

The LSR WG has placed draft-acee-lsr-ospfv3-extended-lsa-yang in state
Call For Adoption By WG Issued (entered by Christian Hopps)

The document is available at
https://datatracker.ietf.org/doc/draft-acee-lsr-ospfv3-extended-lsa-yang/

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

[Lsr] The LSR WG has placed draft-acee-lsr-ospf-yang-augmentation-v1 in state "Call For Adoption By WG Issued"

[IETF Secretariat]

The LSR WG has placed draft-acee-lsr-ospf-yang-augmentation-v1 in state
Call For Adoption By WG Issued (entered by Christian Hopps)

The document is available at
https://datatracker.ietf.org/doc/draft-acee-lsr-ospf-yang-augmentation-v1/

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

[Lsr] WG Adoption poll for draft-acee-lsr-ospf-yang-augmentation-v1-01

[Christian Hopps]

Hi Folks,

This begins a 2 week WG adoption poll for the following:

  https://datatracker.ietf.org/doc/draft-acee-lsr-ospf-yang-augmentation-v1/

Please send any comments to the list by Wednesday Oct 16th, 2019.

Thanks,
Chris.


signature.asc
Description: Message signed with OpenPGP
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

[Lsr] WG Adoption Poll for draft-acee-lsr-ospfv3-extended-lsa-yang-06

[Christian Hopps]

Hi Folks,

This begins a 2 week WG adoption poll for the following:

  https://datatracker.ietf.org/doc/draft-acee-lsr-ospfv3-extended-lsa-yang/

Please send any comments to the list by Wednesday Oct 16th, 2019.

Thanks,
Chris.


signature.asc
Description: Message signed with OpenPGP
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Roman Danyliw's Discuss on draft-ietf-isis-yang-isis-cfg-40: (with DISCUSS)

[Roman Danyliw]

Hi Acee!

You're proposed edits would address my DISCUSS point.  Thanks for this clarity.

> -Original Message-
> From: Acee Lindem (acee) [mailto:a...@cisco.com]
> Sent: Wednesday, October 02, 2019 9:52 AM
> To: Roman Danyliw ; The IESG 
> Cc: draft-ietf-isis-yang-isis-...@ietf.org; Yingzhen Qu
> ; aretana.i...@gmail.com; lsr-cha...@ietf.org;
> lsr@ietf.org
> Subject: Re: Roman Danyliw's Discuss on draft-ietf-isis-yang-isis-cfg-40: 
> (with
> DISCUSS)
> 
> Hi Roman,
> 
> On 10/1/19, 4:28 PM, "Roman Danyliw via Datatracker" 
> wrote:
> 
> Roman Danyliw has entered the following ballot position for
> draft-ietf-isis-yang-isis-cfg-40: Discuss
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-isis-yang-isis-cfg/
> 
> 
> 
> --
> DISCUSS:
> --
> 
> Section 7.  A DISCUSS for discussion.  Thanks for this enumeration of
> writeable
> and readable nodes which could be considered sensitive.  Per the list of
> nodes
> that could expose the topology of the network, wouldn’t the following also
> have
> sensitive topology information:
> 
> -- /isis/local-rib
> 
> Although not as detailed as the Link State Database, a case could also be
> made for the local RIB. I'll add it to the sensitive operational data.

Thanks.

> -- /isis/hostnames
> 
> These is basically a mapping of hostnames to ISO System IDs. The ISO System
> ID is really only used by IS-IS (native CLNS is a thing of the past). I 
> really don't
> see this as being all that useful to an attacker.

Ok.

> Furthermore, shouldn’t the log files also be protected as the errors or
> status
> posted there could also leak topology information: -- /isis/spf-log --
> /isis/lsp-log
> 
> This doesn't include the contents of the LSP - only the LSP ID that caused the
> SPF. I don't see how this would that sensitive - other than that someone
> accessing the SPF and LSP logs could determine that the IS-IS Routing domain
> is volatile.

Ok.

> Thanks,
> Acee
> 
> 
> 
> 
> 
> 

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

Re: [Lsr] Roman Danyliw's Discuss on draft-ietf-isis-yang-isis-cfg-40: (with DISCUSS)

[Acee Lindem (acee)]

Hi Roman, 

On 10/1/19, 4:28 PM, "Roman Danyliw via Datatracker"  wrote:

Roman Danyliw has entered the following ballot position for
draft-ietf-isis-yang-isis-cfg-40: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-isis-yang-isis-cfg/



--
DISCUSS:
--

Section 7.  A DISCUSS for discussion.  Thanks for this enumeration of 
writeable
and readable nodes which could be considered sensitive.  Per the list of 
nodes
that could expose the topology of the network, wouldn’t the following also 
have
sensitive topology information:

-- /isis/local-rib

Although not as detailed as the Link State Database, a case could also be made 
for the local RIB. I'll add it to the sensitive operational data. 

-- /isis/hostnames

These is basically a mapping of hostnames to ISO System IDs. The ISO System ID 
is really only used by IS-IS (native CLNS is a thing of the past). I really 
don't see this as being all that useful to an attacker. 

Furthermore, shouldn’t the log files also be protected as the errors or 
status
posted there could also leak topology information: -- /isis/spf-log -- 
/isis/lsp-log

This doesn't include the contents of the LSP - only the LSP ID that caused the 
SPF. I don't see how this would that sensitive - other than that someone 
accessing the SPF and LSP logs could determine that the IS-IS Routing domain is 
volatile. 

Thanks,
Acee







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