Subject: Re: [i2rs] Shepherd review of draft-ietf-i2rs-problem-statement-04

From: Alia Atlas <[email-masked]>
Date: Tue, 6 Jan 2015 16:53:34 -0500

Hi Qin,

Thanks for the review and taking on being document shepherd!

On Wed, Dec 17, 2014 at 10:10 PM, Qin Wu <[email-masked]> wrote:

>  Hi, authors
>
>
>
> I have been selected as the document shepherd for this draft.
>
> I think this is an important draft and support publication.
>
>
>
> Having reviewed this document (v-04), I have a number of editorial
> comments:
>
>
>
> 1. Section 2 said:
>
>
>
> "The second critical aspect are meaningful data-models for information
>
>    in the routing system and in a topology database .  "
>
>
>
> There is a typo in it, Suggested editorial change is:
>
> “The second critical aspect of I2RS is a set of meaningful data-models for
>
> information in the routing system and in a topology database.”
>

Agreed and fixed.

>  2.Section 2 said:
>
> " The data models should translate into a concise transfer syntax that is
> straightforward for applications to use (e.g., a Web Services design
> paradigm)."
>
>
>
> By reading this sentence, it is not clear what is translated?
>
> data model or information from the routing system?
>
>
>
> Suggested change:
>
> The data models information sent in I2RS protocol should be able to be
> translated into a concise transfer syntax that is straightforward for
> applications to use (e.g., a Web Services design paradigm).
>

I've changed it slightly to
"The data models should translate into a concise transfer syntax, sent via
  the I2RS protocol, that is straightforward for applications to
  use (e.g., a Web Services design paradigm)."

The data model is in YANG - but the transfer syntax might be xml or google
protobufs or...

 3. Section 3, first paragraph said:
>
> "In addition, by having I2RS focus
>
>    initially on interfaces to the RIB layer (e.g.  RIB, LIB, multicast
>
>    RIB, policy-based routing), the ability to use routing indirection
>
>    allows flexibility and functionality that can't be as easily obtained
>
>    at the forwarding layer."
>
>
>
> I think here we should highlight the downside of using existing mechanism.
>
>
>
> Suggest the following replacement text:
>
> “
>
> With an I2RS interface to the RIB layer  (e.g. RIB, LIB, multicast RIB,
> policy-based routing), this provides flexibility and functionality for
> route indirection of next-hops.
>
> This flexibility and functionality cannot be easily obtained at the
> forwarding layer, or obtain via the relevant MIB modules  (for example
> RFC4292) which lack the necessary generality and flexibility.
>
> “
>

I'm fine with not highlighting the downsides more clearly.   I prefer the
existing text.

>  4.Section 4, second paragraph said:
>
> " Detailed topological state that provides more information than the
> current
>
>    functional status is needed by applications; only the active paths or
>
>    links are known versus those potentially available  (e.g.
>
>    administratively down) or unknown (e.g. to peers or customers) to the
>
>    routing topology. "
>
> Two sentences seems disconnected, suggested replacement text as below:
>
> “
>
> Detailed topological state which provides more information than the current
>
> functional status is needed by applications. An example of this
>
> lack of detailed information is that only the active paths or
>
> links are known versus those potentially available paths (e.g.
>
> administratively down) or unknown paths (e.g. to peers or customers) to the
>
> routing topology.
>
> “
>

Slightly word-smithed to:

" Detailed topological state that provides more information
      than the current functional status (e.g. active paths and links)
      is needed by applications.  Examples of missing information
      include paths or link that are potentially available (e.g.
      administratively down) or unknown (e.g. to peers or customers)
      to the routing topology."

>  5. Section 8: Security consideration section
>
> Would it be better to add something to say this document is problem
> statement draft
>
> Security considerations are not addressed in this problem statement only
> document. Instead it will be addressed in some protocol documents in the
> future.
>
>
>
> Suggested Replacement for section 8:
>
> “
>
> Security is a key aspect of any  protocol that allows state installation
> and extracting of detailed router state. The I2RS protocol and data models
> will need to define security requirements such as such as authorization and
> authentication levels.
>
>
>
> This document as an informational problem statement does not have any
> security considerations.
>
> “
>

As you may have seen from my email exchange with Russ Housley, I've updated
the Security Considerations
section to:

"Security is a key aspect of any protocol that allows state
      installation and extracting of detailed router state.  The
      security considerations are discussed in
[draft-ietf-i2rs-architecture].
      Briefly, the I2RS Agent
      is assumed to have a separate authentication and authorization
      channel by which it can validate both the identity and the
      permissions associated with an I2RS Client.  Mutual
      authentication between the I2RS Agent and I2RS Client is
      required.  Different levels of integrity, confidentiality, and
      replay protection are relevant for different aspects of I2RS."

>
>
> 6. Section 9
>
> Reference  [I-D.gredler-idr-ls-distribution] should be updated to
> [I-D.ietf-idr-ls-distribution]
>

Fixed

Thanks again!
Alia

>  Regards!
>
> -Qin
>
> _______________________________________________
> i2rs mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i2rs
>
>

---

From: Qin Wu <[email-masked]>
Date: Thu, 8 Jan 2015 05:00:05 +0000

Thanks for addressing my comments, your proposed changes work for me.

Regards!
-Qin
发件人: Alia Atlas [mailto:[email-masked]]
发送时间: 2015年1月7日 5:54
收件人: Qin Wu
抄送: [email-masked]; [email-masked]
主题: Re: [i2rs] Shepherd review of draft-ietf-i2rs-problem-statement-04

Hi Qin,

On Wed, Dec 17, 2014 at 10:10 PM, Qin Wu <[email-masked]<mailto:[email-masked]>> wrote:
Hi, authors

Having reviewed this document (v-04), I have a number of editorial comments:

1. Section 2 said:

Agreed and fixed.

2.Section 2 said:
" The data models should translate into a concise transfer syntax that is straightforward for applications to use (e.g., a Web Services design paradigm)."

Suggested change:
The data models information sent in I2RS protocol should be able to be translated into a concise transfer syntax that is straightforward for applications to use (e.g., a Web Services design paradigm).

The data model is in YANG - but the transfer syntax might be xml or google protobufs or...

Suggest the following replacement text:
“
With an I2RS interface to the RIB layer  (e.g. RIB, LIB, multicast RIB, policy-based routing), this provides flexibility and functionality for route indirection of next-hops.
This flexibility and functionality cannot be easily obtained at the forwarding layer, or obtain via the relevant MIB modules  (for example RFC4292) which lack the necessary generality and flexibility.
“

I'm fine with not highlighting the downsides more clearly.   I prefer the existing text.

" Detailed topological state that provides more information than the current

5. Section 8: Security consideration section
Would it be better to add something to say this document is problem statement draft
Security considerations are not addressed in this problem statement only document. Instead it will be addressed in some protocol documents in the future.

Suggested Replacement for section 8:
“
Security is a key aspect of any  protocol that allows state installation and extracting of detailed router state. The I2RS protocol and data models will need to define security requirements such as such as authorization and authentication levels.

This document as an informational problem statement does not have any security considerations.
“

As you may have seen from my email exchange with Russ Housley, I've updated the Security Considerations
section to:

      security considerations are discussed in [draft-ietf-i2rs-architecture].

6. Section 9
Reference  [I-D.gredler-idr-ls-distribution] should be updated to  [I-D.ietf-idr-ls-distribution]

Fixed

Thanks again!
Alia

Regards!
-Qin

_______________________________________________
i2rs mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/i2rs

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 8 Jan 2015 08:58:44 -0500

Qin:

Thank you for reviewing the changes to the problem statement. 

Sue 

From: i2rs [mailto:[email-masked]] On Behalf Of Qin Wu
Sent: Thursday, January 08, 2015 12:00 AM
To: Alia Atlas
Cc: [email-masked]; [email-masked]
Subject: Re: [i2rs] Shepherd review of draft-ietf-i2rs-problem-statement-04

Regards!

-Qin

Hi Qin,

Hi, authors

1. Section 2 said:

Agreed and fixed. 

2.Section 2 said:

Suggested change:  

“

“

   routing topology. "

“

routing topology. 

“

 

“

“

section to:

      Briefly, the I2RS Agent

 

6. Section 9

Fixed

Thanks again!

Alia

Regards!

-Qin