Re: [OPSAWG] Roman Danyliw's Discuss on draft-ietf-opsawg-sdi-10: (with DISCUSS and COMMENT)

[Warren Kumari]

On Thu, May 21, 2020 at 10:09 AM Roman Danyliw  wrote:
>
> Hi Warren!
>
> Thanks for the response and -11.  More inline ...
>
> > -Original Message-
> > From: Warren Kumari 
> > Sent: Tuesday, May 19, 2020 2:35 PM
> > To: Roman Danyliw 
> > Cc: The IESG ; draft-ietf-opsawg-...@ietf.org; OpsAWG-Chairs
> > ; opsawg ; Michael Richardson
> > 
> > Subject: Re: Roman Danyliw's Discuss on draft-ietf-opsawg-sdi-10: (with
> > DISCUSS and COMMENT)
> >
> > On Mon, May 18, 2020 at 6:20 PM Roman Danyliw via Datatracker
> >  wrote:
> > >
> > > Roman Danyliw has entered the following ballot position for
> > > draft-ietf-opsawg-sdi-10: 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-opsawg-sdi/
> > >
> > >
> > >
> > > --
> > > DISCUSS:
> > > --
> > >
> > > ** Section 3.2.  If keying material is being distributed as a
> > > certificate, do the expected behaviors of certificate process apply?
> > > For example, how is expiration handled?
> > >
> > > --  If a customer downloads a certificate from the publication server
> > > and it is expired, what should be done?
> > >
> > > -- If a certificate is loaded in the TPM of the device, should the
> > > client stop accepting configurations if it expires?
>
> The text in -11 works for me.  If you think there are alternatives to using 
> X.509 in this reference architecture it might be worth mentioning.
>
> > > ** Section 4.3.  “After retrieving the config file, the device needs
> > > to determine if it is encrypted or not.  If it is not encrypted, the
> > > existing behavior is used.”  What downgrade protection is assumed or
> > recommended here.
> > > A rogue data center employee could re-target a DHCP response to a
> > > server of choice which provides only unencrypted, tainted
> > > configuration.  It would seem that a device expecting an encrypted
> > > configuration should not accepted unencrypted ones (or at least this 
> > > should
> > be a policy consideration).
> > >
> >
> > Thank you very much for your review.
> >
> > I have addressed these (and below) in
> > https://github.com/wkumari/draft-wkumari-opsawg-
> > sdi/commit/22d2ad52983e03309796867db22b88a5960bf039
> > (and will be posting a new version of the draft soon, once I address other
> > comments as well).
> > For those following along at home, Roman kindly provided me some text to
> > clarify the above.
>
> For the downgrade issue noted above.  I think we need a little more text.  My 
> concern is around the following text:
>
> Section 4.3:
> After retrieving the configuration file, the device needs to
> determine if it is encrypted or not. If it is not encrypted, the
> existing behavior is used.
>
> If a new device supports this architecture and the deployment environment 
> supports it too (which should be known), but the device still gets an 
> unencrypted config, that should be a sign of something suspicious.  I would 
> envision language here that says that devices should abort.

Added: "If the device has been configured to only support encrypted
configuration
and determines that the configuration file is not encrypted,
it should abort."

>
> > >
> > > --
> > > COMMENT:
> > > --
> > >
> > > ** I struggled a bit to understand where this solution was applicable.
> > > For
> > > example:
> > >
> > > Abstract: “This document extends existing auto-install / Zero-Touch
> > > Provisioning mechanisms to make the process more secure.”
> > >
> > > Section 1: “this document layers security onto existing auto-install
> > > solutions to provide a secure method to initially configure new devices”.
> > >
> > > -- Which “auto-install” and “zero touch provision mechanisms” is this
> > updating?
> >
> > I added some text to clean this up, and point at the archetype  - Cisco's
> > AutoInstall - https://www.cisco.com/c/en/us/td/docs/ios-
> > xml/ios/fundamentals/configuration/15mt/fundamentals-15-mt-book/cf-
> > autoinstall.html
> > It is by no means the only org which does this, but it has been around for 
> > a long
> > time, and is probably best known...
> >
> > >
> > > -- What exact preconditions are necessary to make this “solution”
> > > (reference
> > > architecture?) applicable?  Would this still be useful if the 
> > > “auto-install”
> > > mechanism was encrypted?  What non-DHCP 

Re: [OPSAWG] Benjamin Kaduk's No Objection on draft-ietf-opsawg-sdi-12: (with COMMENT)

[Warren Kumari]

On Fri, Jun 19, 2020 at 6:22 PM Benjamin Kaduk via Datatracker
 wrote:
>
> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-opsawg-sdi-12: 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-opsawg-sdi/
>
>
>
> --
> COMMENT:
> --
>
> Thanks for the updates in the -12 (and -11?  My notes claim I reviewed the 
> -10,
> though the datatracker history says it was the -11; perhaps there was some 
> skew
> between when I opened the doc and balloted).  They get most of the way to 
> where
> I want us to be, so I'm switching to No Objection.  That said, the Abstract 
> and
> Introduction still feel like they're slightly overstating the confidentiality
> protection attainable with this mechanism:
>
> The Abstract currently says "to provide confidentiality to initial 
> configuration
> during bootstrapping", but we may need to hedge that a bit more, e.g., that
> this is partial or limited confidentiality.  Similarly, Section 1 currently
> says "while maintaining confidentiality of the initial configuration", and
> would get similar treatment.
>
> Finally, I see that you took my suggestion of using "directory service" 
> instead
> of "Certificate Publication Server".  It may be worth a reference for this
> concept -- e.g., Section 2.1 of RFC 5280 references both [X.500] and RFC 4510
> as potential ways to provide directory service for obtaining certificates.
>
>
>

Done, done and done (in github version).

W


-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] CALL FOR ADOPTION: draft-barguil-opsawg-l2sm-l2nm

[MUÑOZ , LUIS ANGEL , Vodafone Spain]

Hello

I support this work as a complement to other pieces we intend to use for 
network driven model management.
It is planned to push the adoption as an operator as soon as it's ready.

Thanks and regards
Luis

De: OPSAWG  en nombre de Joe Clarke (jclarke) 

Enviado: martes, 16 de junio de 2020 9:17
Para: opsawg 
Asunto: [OPSAWG] CALL FOR ADOPTION: draft-barguil-opsawg-l2sm-l2nm

Hello, opsawg.  I hope everyone is doing well.

This starts a two-week poll for adoption of the L2 network module document.  
There does seem to be interest in this work, and it is progressing nicely in 
GitHub with side meetings.  There appears to be questions on what will be 
broken out into commonality between this module and the L3NM (work which is 
also underway).  So while we anticipate changes to this draft, the chairs think 
it?s reached a point where we?d like to see if the WG wants to formally adopt 
the work.

Please reply on-list with your comments on the draft and whether or not you 
support its WG adoption.  We will conclude this call on June 30, 2020.

Thanks.

Joe
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg



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
-- next part --
An HTML attachment was scrubbed...
URL: 


--

Message: 7
Date: Tue, 16 Jun 2020 15:50:53 +
From: SAMIER BARGUIL GIRALDO

To: Oscar Gonz?lez de Dios  ,
Italo Busi , tom petch ,
"adr...@olddog.co.uk" ,  "'Joe Clarke (jclarke)'"

Cc: 'opsawg' 
Subject: Re: [OPSAWG] Common service models types yang ?
Message-ID:



Content-Type: text/plain; charset="iso-8859-1"

Hello all,

Based on the previous discussion, I have updated a proposal of the vpn-common 
yang file (https://github.com/IETF-OPSAWG-WG/l3nm/pull/122).
[https://avatars1.githubusercontent.com/u/60149792?s=400=4]
vpn-common extended proposal and l3vn-ntw whiout gruopings. by sbarguil ? Pull 
Request #122 ? 
IETF-OPSAWG-WG/l3nm
L3NM no groupings VPN common updates with features, typedef and identityes.
github.com

Additionally, I have removed all the un-reused groupings of the L3NM as the 
yang-doctor suggested (https://github.com/IETF-OPSAWG-WG/l3nm/issues/111) to 
consolidadete the whole structure directly.
[https://avatars1.githubusercontent.com/u/60149792?s=400=4]
Fix issues from Yang doctor review ? Issue #111 ? 
IETF-OPSAWG-WG/l3nm
Yang doctor review in: 
https://datatracker.ietf.org/doc/draft-ietf-opsawg-l3sm-l3nm/reviewrequest/13293/
 https://mailarchive.ietf.org/arch/msg/yang-doctors/dO9I3gdwFL7wL-cm-fpXSUhOlzY 
Reviewer: Rad...
github.com
Currently, I have created a parallel file for revsion. Once the revision is 
complete I can copy as the last yang-file.

The diff file and the trees are attached, so you can see the differences.

Reagards,


Samier Barguil
Transport & IP Networks | GCTIO - Technology | CIT Centro Integrado de 
Transporte |

M?vil +57 3017026430

M?vil +34 665416074

E-mail samier.barguilgiraldo@telefonica.com

E-mail samier.barg...@wipro.com

Re: [OPSAWG] CALL FOR ADOPTION: draft-barguil-opsawg-l2sm-l2nm

[LOPEZ, MANUEL JULIAN, Vodafone Spain]

I Support the WG adoption

Enviado desde Outlook Mobile

From: OPSAWG  on behalf of Oscar González de Dios 

Sent: Monday, June 22, 2020 1:19:17 PM
To: Joe Clarke (jclarke) ; opsawg 

Subject: Re: [OPSAWG] CALL FOR ADOPTION: draft-barguil-opsawg-l2sm-l2nm

CYBER SECURITY WARNING: This email is from an external source - be careful of 
attachments and links. Please follow the Cyber Code and report suspicious 
emails.

Hi Joe,

As co-author of the draft, I support the adoption.

I think it is a relevant piece of work for data model driven network management 
covering layer 2 services, complementing existing works.

Best Regards,

Oscar



-Mensaje original-
De: OPSAWG  En nombre de Joe Clarke (jclarke)
Enviado el: martes, 16 de junio de 2020 16:18
Para: opsawg 
Asunto: [OPSAWG] CALL FOR ADOPTION: draft-barguil-opsawg-l2sm-l2nm

Hello, opsawg.  I hope everyone is doing well.

This starts a two-week poll for adoption of the L2 network module document.  
There does seem to be interest in this work, and it is progressing nicely in 
GitHub with side meetings.  There appears to be questions on what will be 
broken out into commonality between this module and the L3NM (work which is 
also underway).  So while we anticipate changes to this draft, the chairs think 
it’s reached a point where we’d like to see if the WG wants to formally adopt 
the work.

Please reply on-list with your comments on the draft and whether or not you 
support its WG adoption.  We will conclude this call on June 30, 2020.

Thanks.

Joe
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg



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
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg


C2 General
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] [E] Fwd: Re: CALL FOR ADOPTION: draft-barguil-opsawg-l2sm-l2nm

[luay . jalil=40verizon . com]

I support this work and WG adoption

Thanks,
Luay

From: Luay Jalil 
Date: Tuesday, June 23, 2020 at 11:08 AM
To: Luay 
Subject: [E] Fwd: [OPSAWG] CALL FOR ADOPTION: draft-barguil-opsawg-l2sm-l2nm

Luay

-Original Message-
From: Joe Clarke (jclarke) [mailto:jcla...@cisco.com]
To: opsawg 
Subject: [OPSAWG] CALL FOR ADOPTION: draft-barguil-opsawg-l2sm-l2nm
 Hello, opsawg.  I hope everyone is doing well.
 This starts a two-week poll for adoption of the L2 network module document.
There does seem to be interest in this work, and it is progressing nicely in
GitHub with side meetings.  There appears to be questions on what will be
broken out into commonality between this module and the L3NM (work which
is also underway).  So while we anticipate changes to this draft, the chairs
think it’s reached a point where we’d like to see if the WG wants to formally
adopt the work.
 Please reply on-list with your comments on the draft and whether or not you
support its WG adoption.  We will conclude this call on June 30, 2020.
 Thanks.

Joe

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

___

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] CALL FOR ADOPTION: draft-barguil-opsawg-l2sm-l2nm

[Italo Busi]

I support WG adoption of this document

I think the relationship between this model and the model in 
draft-ietf-ccamp-client-signal-yang could be clarified by progressing this work 
as a WG document

Italo

> -Original Message-
> From: Joe Clarke (jclarke) [mailto:jcla...@cisco.com]
> Sent: martedì 16 giugno 2020 16:18
> To: opsawg 
> Subject: [OPSAWG] CALL FOR ADOPTION: draft-barguil-opsawg-l2sm-l2nm
> 
> Hello, opsawg.  I hope everyone is doing well.
> 
> This starts a two-week poll for adoption of the L2 network module document.
> There does seem to be interest in this work, and it is progressing nicely in
> GitHub with side meetings.  There appears to be questions on what will be
> broken out into commonality between this module and the L3NM (work which
> is also underway).  So while we anticipate changes to this draft, the chairs
> think it’s reached a point where we’d like to see if the WG wants to formally
> adopt the work.
> 
> Please reply on-list with your comments on the draft and whether or not you
> support its WG adoption.  We will conclude this call on June 30, 2020.
> 
> Thanks.
> 
> Joe
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg