Subject: Re: [Panic] Scope Draft is Available

From: Robert Moskowitz <[email-masked]>
Date: Thu, 15 Jun 2017 16:37:46 -0400

David,

Do you have an update to your draft?

I don't see anything past the Apr 11 01.txt draft.

thanks

On 05/19/2017 10:09 AM, Waltermire, David A. (Fed) wrote:
>
> Diego, thanks for the edits.
>
> All,
>
> I am going to drop this text into an update of the scope draft. I’ll 
> wait until Monday to work on posting the draft update. Please let me 
> know if any other changes to the draft are desired.
>
> Thanks,
>
> Dave
>
> *From:*Panic [mailto:[email-masked]] *On Behalf Of *Diego R. Lopez
> *Sent:* Friday, May 19, 2017 2:23 AM
> *To:* Waltermire, David A. (Fed) <[email-masked]>
> *Cc:* [email-masked]; Panos Kampanakis (pkampana) <[email-masked]>
> *Subject:* Re: [Panic] Scope Draft is Available
>
> Hi,
>
> I agree with David’s proposal, with just a few minor changes with 
> respect to the original text, to make it more general, completely 
> covering the virtual cases (NFV) and eliminating the term “device” to 
> avoid too many equivalences...
>
> Network operators need to know what is connected to their 
> organization's networks so that they can properly manage those network 
> elements. Managing these network endpoints, consisting of physical and 
> virtual network infrastructure, requires access to information 
> pertaining to them, including endpoint identity, the identity of 
> software installed on the element, and the configuration setting 
> values for the installed software. This information can be collected 
> from different classes of elements over different protocols and using 
> different data models. PANIC will identify a standardized solution to 
> collect posture information for network element, and allow that 
> information to be shared with authorized users and elements on the 
> network supporting security automation. PANIC aims to reuse available 
> standards for posture assessment where possible. The PANIC effort will 
> avoid redefining information exchange technologies for use cases that 
> have already been defined.
>
> Be goode,
>
>     On 18 May 2017, at 20:01 , Waltermire, David A. (Fed)
>     <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Panos, thanks for providing text.
>
>     We have participants that are approaching this problem space that
>     are accustomed to using endpoint and network element. How about
>     the following introduction text to draw an equivalence between
>     these terms?
>
>     Network operators need to know what is connected to their
>     organization's networks so that they can properly manage those
>     network elements. Managing these network elements, consisting of
>     physical and virtual network infrastructure devices, requires
>     access to information pertaining to these endpoint devices,
>     including device identity, the identity of software installed on
>     the endpoint, and the configuration setting values for the
>     installed software. This information can be collected from
>     different classes of endpoints over different protocols and using
>     different data models. PANIC will identify a standardized solution
>     to collect posture information for network devices, and allow that
>     information to be shared with authorized users and devices on the
>     network supporting security automation. PANIC aims to reuse
>     available standards for posture assessment where possible. The
>     PANIC effort will avoid redefining information exchange
>     technologies for use cases that have already been defi
>     ned.
>
>     Also, I added your text to the security considerations section. I
>     will post this in the -02 revision once we sort out the Introduction.
>
>     Thanks,
>     Dave
>
>
>         -----Original Message-----
>         From: Panos Kampanakis (pkampana) [mailto:[email-masked]]
>         Sent: Thursday, May 18, 2017 12:30 PM
>         To: Waltermire, David A. (Fed) <[email-masked]
>         <mailto:[email-masked]>>; [email-masked]
>         <mailto:[email-masked]>
>         Subject: RE: Scope Draft is Available
>
>         ACK. Below some proposed text:
>
>         For the Security Considerations Section:
>           Further discussion here will address the threat introduced
>         to the network
>         elements by the posture information collection. There should
>         be protections
>         implemented to prevent the element from being vulnerable to
>         DoS attacks
>         by frequent polling or pushing of posture data.
>
>         For the Introduction Section:
>           ...automation. PANIC aims to reuse available standards for
>         posture
>         assessment where possible. It will avoid redefining info exchange
>         technologies for usecases that have already been defined.
>
>         For the Introduction Section:
>           ...manage those
>           endpoints. Endpoints / Elements include hardware, software
>         of virtual
>         network infrastructure devices.
>
>
>
>
>
>         hardware, software or virtual (NFV fails in this
>
>             category)
>
>
>
>         -----Original Message-----
>         From: Waltermire, David A. (Fed)
>         [mailto:[email-masked]]
>         Sent: Thursday, May 18, 2017 10:59 AM
>         To: Panos Kampanakis (pkampana) <[email-masked]
>         <mailto:[email-masked]>>; [email-masked]
>         <mailto:[email-masked]>
>         Subject: RE: Scope Draft is Available
>
>         Panos,
>
>         Thank you for providing feedback on the PANIC scope draft.
>
>         Comments are inline below.
>
>
>             -----Original Message-----
>             From: Panos Kampanakis (pkampana) [mailto:[email-masked]]
>             Sent: Thursday, May 18, 2017 10:37 AM
>             To: Waltermire, David A. (Fed) <[email-masked]
>             <mailto:[email-masked]>>;
>             [email-masked] <mailto:[email-masked]>
>             Subject: RE: Scope Draft is Available
>
>             Hi David,
>
>             The document is clear.
>
>             One semantic objection I have is about the use of the word
>             endpoint. I
>             believe the term is commonly used for user machines
>             (laptops, cells,
>             tablets) . Network element or element is a little clearer.
>
>
>         I don't have a dog in this fight. I am happy to go either way
>         (e.g., endpoint,
>         network element) if there is a preference in the group for one
>         term or the
>         other. I'd like to hear other opinions on this.
>
>
>             A susggestion: The security section could mention the
>             importance of
>             not introducing security concerns with the posture info
>             collection.
>             For example a device should not be DoSable by too many
>             polls, or it
>             should not push often enough that would introduce
>             performance concerns
>
>         etc.
>
>         I think this is a good idea. Do you have some text in mind to
>         drop in?
>
>
>             I think it will also be beneficial to be explicit about
>             the types of
>             network elements. In the broad technologies that exist
>             today, these
>             elements could be hardware, software or virtual (NFV fails
>             in this
>             category). All of those should be in scope for this work.
>
>
>         All of these are in scope in my view.
>
>
>             Side comment: I would like this standardization effort to
>             try to reuse
>             data formats and transports wherever possible and not come
>             up with new
>             posture information descriptions. I think this is a common
>             goal that
>             SACM has as well.
>
>
>         I share this goal as well. Should we document this in the draft?
>
>
>             Thanks,
>             Panos
>
>
>         Regards,
>         Dave
>
>
>             -----Original Message-----
>             From: Panic [mailto:[email-masked]] On Behalf Of
>             Waltermire,
>             David A. (Fed)
>             Sent: Monday, May 15, 2017 11:03 AM
>             To: [email-masked] <mailto:[email-masked]>
>             Subject: [Panic] Scope Draft is Available
>
>             Welcome to the posture assessment through network information
>             collection
>             (PANIC) email list. At the side meeting on March 29th, we
>             started
>             discussing the problem of how to measure the health of network
>             devices. We discussed the need to collect posture
>             information from
>             network devices to support asset, software, vulnerability, and
>             configuration management use cases. We were asked by the
>             group to
>             share a more detailed description of the intended scope
>             for the PANIC
>             effort. The follow draft is an attempt to do
>             so:
>
>             https://datatracker.ietf.org/doc/draft-waltermire-panic-scope/
>
>             We would appreciate review of and comments on this draft.
>             At this
>             point, we want to know if the this scope clearly defines
>             the problem to be
>
>         solved.
>
>             Please let us know if you have any questions or concerns,
>             or if you
>             think the scope draft is adequate.
>
>             Regards,
>             David Waltermire
>
>             _______________________________________________
>             Panic mailing list
>             [email-masked] <mailto:[email-masked]>
>             https://www.ietf.org/mailman/listinfo/panic
>
>
>     _______________________________________________
>     Panic mailing list
>     [email-masked] <mailto:[email-masked]>
>     https://www.ietf.org/mailman/listinfo/panic
>
> --
> "Esta vez no fallaremos, Doctor Infierno"
>
> Dr Diego R. Lopez
> Telefonica I+D
> http://people.tid.es/diego.lopez/
>
> e-mail: [email-masked] <mailto:[email-masked]>
> Tel:    +34 913 129 041
> Mobile: +34 682 051 091
> ----------------------------------
>
> ------------------------------------------------------------------------
>
>
> Este mensaje y sus adjuntos se dirigen exclusivamente a su 
> destinatario, puede contener información privilegiada o confidencial y 
> es para uso exclusivo de la persona o entidad de destino. Si no es 
> usted. el destinatario indicado, queda notificado de que la lectura, 
> utilización, divulgación y/o copia sin autorización puede estar 
> prohibida en virtud de la legislación vigente. Si ha recibido este 
> mensaje por error, le rogamos que nos lo comunique inmediatamente por 
> esta misma vía y proceda a su destrucción.
>
> The information contained in this transmission is privileged and 
> confidential information intended only for the use of the individual 
> or entity named above. If the reader of this message is not the 
> intended recipient, you are hereby notified that any dissemination, 
> distribution or copying of this communication is strictly prohibited. 
> If you have received this transmission in error, do not read it. 
> Please immediately reply to the sender that you have received this 
> communication in error and then delete it.
>
> Esta mensagem e seus anexos se dirigem exclusivamente ao seu 
> destinatário, pode conter informação privilegiada ou confidencial e é 
> para uso exclusivo da pessoa ou entidade de destino. Se não é vossa 
> senhoria o destinatário indicado, fica notificado de que a leitura, 
> utilização, divulgação e/ou cópia sem autorização pode estar proibida 
> em virtude da legislação vigente. Se recebeu esta mensagem por erro, 
> rogamos-lhe que nos o comunique imediatamente por esta mesma via e 
> proceda a sua destruição
>
>
>
> _______________________________________________
> Panic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/panic

---

From: Robert Moskowitz <[email-masked]>
Date: Fri, 16 Jun 2017 14:46:12 -0400

The draft is very confusing.  We already have NETCONF/RESTCONF. What 
does PANIC provide that these do not?

I am ASSuMEing that there is a need of more than the NETCONF/RESTCONF 
data model and protocol(s).  This needs to be spelled out.

Is PANIC in competition with NETCONF/RESTCONF?
Is PANIC a bolt-on to NETCONF/RESTCONF?
Is PANIC totally orthogonal to NETCONF/RESTCONF?

It seems that the meeting we had in Chicago pointed that it woud deal 
with data not included in the NETCONF/RESTCONF data model.  It would 
have specific security posture implecations whereas NETCONF/RESTCONF is 
more focused on the running of infrastructure gear.

Can we get this into the draft before Prague?

Bob

On 05/15/2017 11:03 AM, Waltermire, David A. (Fed) wrote:
> Welcome to the posture assessment through network information collection (PANIC) email list. At the side meeting on March 29th, we started discussing the problem of how to measure the health of network devices. We discussed the need to collect posture information from network devices to support asset, software, vulnerability, and configuration management use cases. We were asked by the group to share a more detailed description of the intended scope for the PANIC effort. The follow draft is an attempt to do so:
>
> We would appreciate review of and comments on this draft. At this point, we want to know if the this scope clearly defines the problem to be solved. Please let us know if you have any questions or concerns, or if you think the scope draft is adequate.
>
> Regards,
> David Waltermire
>

---

From: "Waltermire, David A. (Fed)" <[email-masked]>
Date: Fri, 16 Jun 2017 19:11:14 +0000

Hi Bob,

Thanks for asking. We have been working on an update. We hope to post it soon addressing the feedback we have received so far, including addressing the comments from your other email today.

Thanks,
Dave

From: Robert Moskowitz [mailto:[email-masked]]
Sent: Thursday, June 15, 2017 4:38 PM
To: Waltermire, David A. (Fed) <[email-masked]>; Diego R. Lopez <[email-masked]>
Cc: [email-masked]; Panos Kampanakis (pkampana) <[email-masked]>
Subject: Re: [Panic] Scope Draft is Available

David,

thanks

All,

I am going to drop this text into an update of the scope draft. I'll wait until Monday to work on posting the draft update. Please let me know if any other changes to the draft are desired.

Thanks,
Dave

From: Panic [mailto:[email-masked]] On Behalf Of Diego R. Lopez
Sent: Friday, May 19, 2017 2:23 AM
To: Waltermire, David A. (Fed) <[email-masked]><mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; Panos Kampanakis (pkampana) <[email-masked]><mailto:[email-masked]>
Subject: Re: [Panic] Scope Draft is Available

Hi,

I agree with David's proposal, with just a few minor changes with respect to the original text, to make it more general, completely covering the virtual cases (NFV) and eliminating the term "device" to avoid too many equivalences...

Network operators need to know what is connected to their organization's networks so that they can properly manage those network elements. Managing these network endpoints, consisting of physical and virtual network infrastructure, requires access to information pertaining to them, including endpoint identity, the identity of software installed on the element, and the configuration setting values for the installed software. This information can be collected from different classes of elements over different protocols and using different data models. PANIC will identify a standardized solution to collect posture information for network element, and allow that information to be shared with authorized users and elements on the network supporting security automation. PANIC aims to reuse available standards for posture assessment where possible. The PANIC effort will avoid redefining information exchange technologies for use cases that have already been defined.

Be goode,

On 18 May 2017, at 20:01 , Waltermire, David A. (Fed) <[email-masked]<mailto:[email-masked]>> wrote:

We have participants that are approaching this problem space that are accustomed to using endpoint and network element. How about the following introduction text to draw an equivalence between these terms?

Network operators need to know what is connected to their organization's networks so that they can properly manage those network elements. Managing these network elements, consisting of physical and virtual network infrastructure devices, requires access to information pertaining to these endpoint devices, including device identity, the identity of software installed on the endpoint, and the configuration setting values for the installed software. This information can be collected from different classes of endpoints over different protocols and using different data models. PANIC will identify a standardized solution to collect posture information for network devices, and allow that information to be shared with authorized users and devices on the network supporting security automation. PANIC aims to reuse available standards for posture assessment where possible. The PANIC effort will avoid redefining information exchange technologies for use cases that have already been defi
ned.

Also, I added your text to the security considerations section. I will post this in the -02 revision once we sort out the Introduction.

Thanks,
Dave

-----Original Message-----
From: Panos Kampanakis (pkampana) [mailto:[email-masked]]
Sent: Thursday, May 18, 2017 12:30 PM
To: Waltermire, David A. (Fed) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: Scope Draft is Available

For the Security Considerations Section:
  Further discussion here will address the threat introduced to the network
elements by the posture information collection. There should be protections
implemented to prevent the element from being vulnerable to DoS attacks
by frequent polling or pushing of posture data.

For the Introduction Section:
  ...automation. PANIC aims to reuse available standards for posture
assessment where possible. It will avoid redefining info exchange
technologies for usecases that have already been defined.

For the Introduction Section:
  ...manage those
  endpoints. Endpoints / Elements include hardware, software of virtual
network infrastructure devices.

category)

-----Original Message-----
From: Waltermire, David A. (Fed) [mailto:[email-masked]]
Sent: Thursday, May 18, 2017 10:59 AM
To: Panos Kampanakis (pkampana) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: Scope Draft is Available

Panos,

-----Original Message-----
From: Panos Kampanakis (pkampana) [mailto:[email-masked]]
Sent: Thursday, May 18, 2017 10:37 AM
To: Waltermire, David A. (Fed) <[email-masked]<mailto:[email-masked]>>;
[email-masked]<mailto:[email-masked]>
Subject: RE: Scope Draft is Available

Hi David,

The document is clear.

One semantic objection I have is about the use of the word endpoint. I
believe the term is commonly used for user machines (laptops, cells,
tablets) . Network element or element is a little clearer.

I don't have a dog in this fight. I am happy to go either way (e.g., endpoint,
network element) if there is a preference in the group for one term or the
other. I'd like to hear other opinions on this.

A susggestion: The security section could mention the importance of
not introducing security concerns with the posture info collection.
For example a device should not be DoSable by too many polls, or it
should not push often enough that would introduce performance concerns
etc.

I think this is a good idea. Do you have some text in mind to drop in?

I think it will also be beneficial to be explicit about the types of
network elements. In the broad technologies that exist today, these
elements could be hardware, software or virtual (NFV fails in this
category). All of those should be in scope for this work.

Side comment: I would like this standardization effort to try to reuse
data formats and transports wherever possible and not come up with new
posture information descriptions. I think this is a common goal that
SACM has as well.

Thanks,
Panos

Regards,
Dave

-----Original Message-----
From: Panic [mailto:[email-masked]] On Behalf Of Waltermire,
David A. (Fed)
Sent: Monday, May 15, 2017 11:03 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [Panic] Scope Draft is Available

Welcome to the posture assessment through network information
collection
(PANIC) email list. At the side meeting on March 29th, we started
discussing the problem of how to measure the health of network
devices. We discussed the need to collect posture information from
network devices to support asset, software, vulnerability, and
configuration management use cases. We were asked by the group to
share a more detailed description of the intended scope for the PANIC
effort. The follow draft is an attempt to do
so:

We would appreciate review of and comments on this draft. At this
point, we want to know if the this scope clearly defines the problem to be
solved.

Please let us know if you have any questions or concerns, or if you
think the scope draft is adequate.

Regards,
David Waltermire

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

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

Dr Diego R. Lopez
Telefonica I+D

e-mail: [email-masked]<mailto:[email-masked]>
Tel:    +34 913 129 041
Mobile: +34 682 051 091
----------------------------------

________________________________

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição

Panic mailing list

[email-masked]<mailto:[email-masked]>

---

From: Jessica Fitzgerald-McKay <[email-masked]>
Date: Mon, 26 Jun 2017 10:47:22 -0400

All,
I have posted an updated draft scope here:
https://datatracker.ietf.org/doc/html/draft-waltermire-panic-scope-02.

I think we have addressed most of the issues brought up on list. I do not
feel I adequately addressed making NAT out of scope (per Daniel's request)
and would like some help on that.

Bob, to your questions on the relationship between our work and netconf, I
think that we could best focus our time on extending YANG to meet the
requirements we derive from this scoping statement. So, I stated that
explicitly in this draft. I'd like to get feedback from the group on that
approach, so please chime in if you like/dislike/love/loathe that idea.

Thanks,
Jess

On Fri, Jun 16, 2017 at 3:11 PM, Waltermire, David A. (Fed) <
[email-masked]> wrote:

> Hi Bob,
>
>
>
> Thanks for asking. We have been working on an update. We hope to post it
> soon addressing the feedback we have received so far, including addressing
> the comments from your other email today.
>
>
>
> Thanks,
>
> Dave
>
>
>
> *From:* Robert Moskowitz [mailto:[email-masked]]
> *Sent:* Thursday, June 15, 2017 4:38 PM
> *To:* Waltermire, David A. (Fed) <[email-masked]>; Diego R.
> Lopez <[email-masked]>
>
> I am going to drop this text into an update of the scope draft. I’ll wait
> until Monday to work on posting the draft update. Please let me know if any
> other changes to the draft are desired.
>
>
>
> Thanks,
>
> Dave
>
>
>
> *From:* Panic [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *Diego R. Lopez
> <[email-masked]>
> <[email-masked]>
> I agree with David’s proposal, with just a few minor changes with respect
> to the original text, to make it more general, completely covering the
> virtual cases (NFV) and eliminating the term “device” to avoid too many
> equivalences...
>
>
>
> Network operators need to know what is connected to their organization's
> networks so that they can properly manage those network elements. Managing
> these network endpoints, consisting of physical and virtual network
> infrastructure, requires access to information pertaining to them,
> including endpoint identity, the identity of software installed on the
> element, and the configuration setting values for the installed software.
> This information can be collected from different classes of elements over
> different protocols and using different data models. PANIC will identify a
> standardized solution to collect posture information for network element,
> and allow that information to be shared with authorized users and elements
> on the network supporting security automation. PANIC aims to reuse
> available standards for posture assessment where possible. The PANIC effort
> will avoid redefining information exchange technologies for use cases that
> On 18 May 2017, at 20:01 , Waltermire, David A. (Fed) <
> [email-masked]> wrote:
>
>
>
> We have participants that are approaching this problem space that are
> accustomed to using endpoint and network element. How about the following
> introduction text to draw an equivalence between these terms?
>
> Network operators need to know what is connected to their organization's
> networks so that they can properly manage those network elements. Managing
> these network elements, consisting of physical and virtual network
> infrastructure devices, requires access to information pertaining to these
> endpoint devices, including device identity, the identity of software
> installed on the endpoint, and the configuration setting values for the
> installed software. This information can be collected from different
> classes of endpoints over different protocols and using different data
> models. PANIC will identify a standardized solution to collect posture
> information for network devices, and allow that information to be shared
> with authorized users and devices on the network supporting security
> automation. PANIC aims to reuse available standards for posture assessment
> where possible. The PANIC effort will avoid redefining information exchange
> Also, I added your text to the security considerations section. I will
> post this in the -02 revision once we sort out the Introduction.
>
> Thanks,
> Dave
>
>
>
> From: Panos Kampanakis (pkampana) [mailto:[email-masked]
> <[email-masked]>]
> To: Waltermire, David A. (Fed) <[email-masked]>; [email-masked]
> From: Waltermire, David A. (Fed) [mailto:[email-masked]
> <[email-masked]>]
> To: Panos Kampanakis (pkampana) <[email-masked]>; [email-masked]
> From: Panos Kampanakis (pkampana) [mailto:[email-masked]
> <[email-masked]>]
> To: Waltermire, David A. (Fed) <[email-masked]>;
> [email-masked]
> From: Panic [mailto:[email-masked] <[email-masked]>] On
> Behalf Of Waltermire,
> David A. (Fed)
> To: [email-masked]
> e-mail: [email-masked]
> Tel:    +34 913 129 041
> Mobile: +34 682 051 091
> ------------------------------
>
>
> Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario,
> puede contener información privilegiada o confidencial y es para uso
> exclusivo de la persona o entidad de destino. Si no es usted. el
> destinatario indicado, queda notificado de que la lectura, utilización,
> divulgación y/o copia sin autorización puede estar prohibida en virtud de
> la legislación vigente. Si ha recibido este mensaje por error, le rogamos
> que nos lo comunique inmediatamente por esta misma vía y proceda a su
> destrucción.
>
> confidential information intended only for the use of the individual or
> entity named above. If the reader of this message is not the intended
> recipient, you are hereby notified that any dissemination, distribution or
> copying of this communication is strictly prohibited. If you have received
> this transmission in error, do not read it. Please immediately reply to the
> sender that you have received this communication in error and then delete
> it.
>
> Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário,
> pode conter informação privilegiada ou confidencial e é para uso exclusivo
> da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário
> indicado, fica notificado de que a leitura, utilização, divulgação e/ou
> cópia sem autorização pode estar proibida em virtude da legislação vigente.
> Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique
> imediatamente por esta mesma via e proceda a sua destruição
>
>
>
>

---

From: Robert Moskowitz <[email-masked]>
Date: Mon, 26 Jun 2017 14:57:12 -0400

Jessica,

Thanksfor updating the draft.  I will give it a read.  Along with dozen 
others I have to get done!  :)

Deadlines.  You have to love 'em.

Bob

On 06/26/2017 10:47 AM, Jessica Fitzgerald-McKay wrote:
> I think we have addressed most of the issues brought up on list. I do 
> not feel I adequately addressed making NAT out of scope (per Daniel's 
> request) and would like some help on that.
>
> Bob, to your questions on the relationship between our work and 
> netconf, I think that we could best focus our time on extending YANG 
> to meet the requirements we derive from this scoping statement. So, I 
> stated that explicitly in this draft. I'd like to get feedback from 
> the group on that approach, so please chime in if you 
> like/dislike/love/loathe that idea.
>
> Thanks,
> Jess
>
> On Fri, Jun 16, 2017 at 3:11 PM, Waltermire, David A. (Fed) 
>     Thanks for asking. We have been working on an update. We hope to
>     post it soon addressing the feedback we have received so far,
>     including addressing the comments from your other email today.
>
>     Thanks,
>
>     Dave
>
>     *From:*Robert Moskowitz [mailto:[email-masked]
>     <mailto:[email-masked]>]
>     *To:* Waltermire, David A. (Fed) <[email-masked]
>     <mailto:[email-masked]>>; Diego R. Lopez
>     <[email-masked] <mailto:[email-masked]>>
>
>
>     *Cc:* [email-masked] <mailto:[email-masked]>; Panos Kampanakis
>     (pkampana) <[email-masked] <mailto:[email-masked]>>
>         I am going to drop this text into an update of the scope
>         draft. I’ll wait until Monday to work on posting the draft
>         update. Please let me know if any other changes to the draft
>         are desired.
>
>         Thanks,
>
>         Dave
>
>         <mailto:[email-masked]>
>         *Cc:* [email-masked] <mailto:[email-masked]>; Panos Kampanakis
>         (pkampana) <[email-masked]> <mailto:[email-masked]>
>         I agree with David’s proposal, with just a few minor changes
>         with respect to the original text, to make it more general,
>         completely covering the virtual cases (NFV) and eliminating
>         the term “device” to avoid too many equivalences...
>
>         network elements. Managing these network endpoints, consisting
>         of physical and virtual network infrastructure, requires
>         access to information pertaining to them, including endpoint
>         identity, the identity of software installed on the element,
>         and the configuration setting values for the installed
>         software. This information can be collected from different
>         classes of elements over different protocols and using
>         different data models. PANIC will identify a standardized
>         solution to collect posture information for network element,
>         and allow that information to be shared with authorized users
>         and elements on the network supporting security automation.
>         PANIC aims to reuse available standards for posture assessment
>         where possible. The PANIC effort will avoid redefining
>         information exchange technologies for use cases that have
>         already been defined.
>
>         Be goode,
>
>             <[email-masked]
>             <mailto:[email-masked]>> wrote:
>
>             We have participants that are approaching this problem
>             space that are accustomed to using endpoint and network
>             element. How about the following introduction text to draw
>             an equivalence between these terms?
>
>             organization's networks so that they can properly manage
>             those network elements. Managing these network elements,
>             consisting of physical and virtual network infrastructure
>             devices, requires access to information pertaining to
>             these endpoint devices, including device identity, the
>             identity of software installed on the endpoint, and the
>             configuration setting values for the installed software.
>             This information can be collected from different classes
>             of endpoints over different protocols and using different
>             data models. PANIC will identify a standardized solution
>             to collect posture information for network devices, and
>             allow that information to be shared with authorized users
>             and devices on the network supporting security automation.
>             PANIC aims to reuse available standards for posture
>             assessment where possible. The PANIC effort will avoid
>             redefining information exchange technologies for use cases
>             that have already been defi
>             ned.
>
>             Also, I added your text to the security considerations
>             section. I will post this in the -02 revision once we sort
>             out the Introduction.
>
>             Thanks,
>             Dave
>
>
>
>                 [mailto:[email-masked]
>                 <mailto:[email-masked]>]
>                     <https://datatracker.ietf.org/doc/draft-waltermire-panic-scope/>
>
>                     <https://www.ietf.org/mailman/listinfo/panic>
>
>
>             <https://www.ietf.org/mailman/listinfo/panic>
>
>         --
>         <http://people.tid.es/diego.lopez/>
>
>         <mailto:[email-masked]>
>         Tel:    +34 913 129 041
>         Mobile: +34 682 051 091
>         destinatario, puede contener información privilegiada o
>         confidencial y es para uso exclusivo de la persona o entidad
>         de destino. Si no es usted. el destinatario indicado, queda
>         notificado de que la lectura, utilización, divulgación y/o
>         copia sin autorización puede estar prohibida en virtud de la
>         legislación vigente. Si ha recibido este mensaje por error, le
>         rogamos que nos lo comunique inmediatamente por esta misma vía
>         y proceda a su destrucción.
>
>         The information contained in this transmission is privileged
>         and confidential information intended only for the use of the
>         individual or entity named above. If the reader of this
>         message is not the intended recipient, you are hereby notified
>         that any dissemination, distribution or copying of this
>         communication is strictly prohibited. If you have received
>         this transmission in error, do not read it. Please immediately
>         reply to the sender that you have received this communication
>         in error and then delete it.
>
>         destinatário, pode conter informação privilegiada ou
>         confidencial e é para uso exclusivo da pessoa ou entidade de
>         destino. Se não é vossa senhoria o destinatário indicado, fica
>         notificado de que a leitura, utilização, divulgação e/ou cópia
>         sem autorização pode estar proibida em virtude da legislação
>         vigente. Se recebeu esta mensagem por erro, rogamos-lhe que
>         nos o comunique imediatamente por esta mesma via e proceda a
>         sua destruição
>
>
>
>
>         <https://www.ietf.org/mailman/listinfo/panic>
>
>     _______________________________________________ Panic mailing list
>     <https://www.ietf.org/mailman/listinfo/panic> 
>

---

From: Jessica Fitzgerald-McKay <[email-masked]>
Date: Mon, 26 Jun 2017 15:08:04 -0400

Completely hear you, Bob. Thanks for finding the time for feedback, we (and
all the other authors/editors whose work you are reviewing) appreciate it!

On Mon, Jun 26, 2017 at 2:57 PM, Robert Moskowitz <[email-masked]>
wrote:

> I have posted an updated draft scope here:  https://datatracker.ietf.org/
> doc/html/draft-waltermire-panic-scope-02.
>
>> destinatário, pode conter informação privilegiada ou confidencial e é para
>> uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o
>> destinatário indicado, fica notificado de que a leitura, utilização,
>> divulgação e/ou cópia sem autorização pode estar proibida em virtude da
>> legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos
>> o comunique imediatamente por esta mesma via e proceda a sua destruição
>>
>>
>>
>>
>> [email-masked] https://www.ietf.org/mailman/listinfo/panic
>
> Panic mailing [email-masked]://www.ietf.org/mailman/listinfo/panic
>
>

---

From: Robert Moskowitz <[email-masked]>
Date: Tue, 27 Jun 2017 15:44:58 -0400

I have reviewed this version and it is much better.

Besides NETCONF, rfc6241, there is RESTCONF, rfc8040.  And there is the 
event notification rfc (5277) and draft.

Perhaps verbage to work with the NETCONF wg is appropriate and invite 
them to the session?

Finally sent 2 in the Intro is too long to read well (58 words!). It 
should be presented as a list for readablity.

Other than these points, I think we are ready to start filling in the 
blanks.

Bob

---

From: "Panos Kampanakis (pkampana)" <[email-masked]>
Date: Wed, 28 Jun 2017 04:14:00 +0000

Hi Jess,

The draft is in good shape. It clearly defines the scope of PANIC.

One suggestion for
      PANIC will
      identify a minimal set of information necessary to manage network
      devices and to support network security functions including
      configuration and vulnerability management.
would be to remove the “necessary to manage network devices“ as I think managing the device is out of scope of PANIC. It is mostly collecting (pull or push) the data that represent the posture, vulnerabilities and insecure configs.

As for NETCONF and YANG, I think these are to good candidate protocols and data representations. But I believe there would be other options to collect and potentially represent the data like RESTCONF, OVAL system characteristics, CPE etc. So, I think NETCONF/YANG should be mentioned but not mandated.

Rgs,
Panos

From: Jessica Fitzgerald-McKay [mailto:[email-masked]]
Sent: Monday, June 26, 2017 10:47 AM
To: Waltermire, David A. (Fed) <[email-masked]>
Cc: Robert Moskowitz <[email-masked]>; Diego R. Lopez <[email-masked]>; [email-masked]; Panos Kampanakis (pkampana) <[email-masked]>
Subject: Re: [Panic] Scope Draft is Available

All,
I have posted an updated draft scope here:  https://datatracker.ietf.org/doc/html/draft-waltermire-panic-scope-02.
I think we have addressed most of the issues brought up on list. I do not feel I adequately addressed making NAT out of scope (per Daniel's request) and would like some help on that.
Bob, to your questions on the relationship between our work and netconf, I think that we could best focus our time on extending YANG to meet the requirements we derive from this scoping statement. So, I stated that explicitly in this draft. I'd like to get feedback from the group on that approach, so please chime in if you like/dislike/love/loathe that idea.
Thanks,
Jess

On Fri, Jun 16, 2017 at 3:11 PM, Waltermire, David A. (Fed) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Bob,

Thanks,
Dave

From: Robert Moskowitz [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Thursday, June 15, 2017 4:38 PM
To: Waltermire, David A. (Fed) <[email-masked]<mailto:[email-masked]>>; Diego R. Lopez <[email-masked]<mailto:[email-masked]>>

Cc: [email-masked]<mailto:[email-masked]>; Panos Kampanakis (pkampana) <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Panic] Scope Draft is Available

David,

thanks

All,

I am going to drop this text into an update of the scope draft. I’ll wait until Monday to work on posting the draft update. Please let me know if any other changes to the draft are desired.

Thanks,
Dave

Hi,

I agree with David’s proposal, with just a few minor changes with respect to the original text, to make it more general, completely covering the virtual cases (NFV) and eliminating the term “device” to avoid too many equivalences...

Be goode,

Thanks,
Dave

-----Original Message-----
From: Panos Kampanakis (pkampana) [mailto:[email-masked]]
Sent: Thursday, May 18, 2017 12:30 PM
To: Waltermire, David A. (Fed) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: Scope Draft is Available

category)

-----Original Message-----
From: Waltermire, David A. (Fed) [mailto:[email-masked]]
Sent: Thursday, May 18, 2017 10:59 AM
To: Panos Kampanakis (pkampana) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: Scope Draft is Available

Panos,

-----Original Message-----
From: Panos Kampanakis (pkampana) [mailto:[email-masked]]
Sent: Thursday, May 18, 2017 10:37 AM
To: Waltermire, David A. (Fed) <[email-masked]<mailto:[email-masked]>>;

Hi David,

The document is clear.

Thanks,
Panos

Regards,
Dave

-----Original Message-----

Regards,
David Waltermire

Dr Diego R. Lopez
Telefonica I+D

Panic mailing list

---

From: "Diego R. Lopez" <[email-masked]>
Date: Wed, 28 Jun 2017 05:52:15 +0000

Hi,

The document looks good to me, thanks!

A couple of comments and a question from my side:

C1: The use of YANG to model the data to be exchanged and stored makes total sense to me, irrespectively of the concrete protocol used for pulls and pushes

C2: As long as device configuration is left out of scope, I don’t see what would be the additional issue with NAT

Q1: Any plans for a gathering in Prague?

Be goode,

On 26 Jun 2017, at 16:47 , Jessica Fitzgerald-McKay <[email-masked]<mailto:[email-masked]>> wrote:

All,

Thanks,
Jess

Thanks,
Dave

David,

thanks

All,

Thanks,
Dave

Hi,

Be goode,

Thanks,
Dave

-----Original Message-----
From: Panos Kampanakis (pkampana) [mailto:[email-masked]]
Sent: Thursday, May 18, 2017 12:30 PM
To: Waltermire, David A. (Fed) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: Scope Draft is Available

category)

-----Original Message-----
From: Waltermire, David A. (Fed) [mailto:[email-masked]]
Sent: Thursday, May 18, 2017 10:59 AM
To: Panos Kampanakis (pkampana) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: Scope Draft is Available

Panos,

-----Original Message-----
From: Panos Kampanakis (pkampana) [mailto:[email-masked]]
Sent: Thursday, May 18, 2017 10:37 AM
To: Waltermire, David A. (Fed) <[email-masked]<mailto:[email-masked]>>;

Hi David,

The document is clear.

Thanks,
Panos

Regards,
Dave

-----Original Message-----

Regards,
David Waltermire

Dr Diego R. Lopez
Telefonica I+D

Panic mailing list

Dr Diego R. Lopez
Telefonica I+D