Re: [Gen-art] Gen-art LC Review of draft-ietf-anima-autonomic-control-plane-13

[Toerless Eckert]

Elwyn, Brian, *: Just quickly:

Thank a lot. there is this looming deadline called March 5th for other work,
so will only be able to get back and seriously work on your review afterwards.

Cheers
Toerless

On Thu, Mar 01, 2018 at 02:45:36PM +1300, Brian E Carpenter wrote:
> Replying as a protagonist -
> 
> First thanks for the really thorough review with many good points.
> 
> Now a few replies in-line:
> 
> On 28/02/2018 15:24, Elwyn Davies wrote:
> > 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-anima-autonomic-control-plane-13.txt
> > Reviewer: Elwyn Davies
> > Review Date: 2016/02/27
> > IETF LC End Date:  2016/02/26
> > IESG Telechat date: (if known) -
> > 
> > Summary:  Not ready.  There are a number of minor issues and a host of nits 
> > and editorial fixes needed.  I would also consider that the expected status 
> > (expeimental vs standards track) ought to be discussed on account of the 
> > areas where it is incomplete (e.g., incompleteness of the key Intent 
> > mechanism).
> 
> An Intent mechanism is not required to build and operate the ACP, and if
> the draft gives that impression, it needs to be fixed.
> 
> > 
> > Major issues:
> > I am sure this has been considered elsewhere, but the amount of future work 
> > and areas where operation might discover problems indicates to me that 
> > maybe this should be an experimental proposal rather than standards track.
> 
> It's chartered as standards track and other drafts have a normative
> dependency on it. So changing the intended status would be very
> problematic. Of course it's a judgment call, but there's nothing
> dubious that it depends on - ULAs, IPSEC, RPL, VRF functionality,
> in fact all the normative references except GRASP and BRSKI are well
> established. (GRASP has a mutual normative reference to this document,
> and is already in the RFC Editor queue; BRSKI is not out of the
> WG yet, so is likely to become a MISSREF.)
> 
> Yes, I'd be happier if I had running code for the ACP, but as far as
> I know that isn't a requirement for Proposed Standard.
>  
> > Minor issues:
> > Clarity regarding limitations of the ACP approach:The document is 
> > relentlessly positive about the ACP approach.  Clearly certain problems 
> > will not allow the ACP to function.  For example it implies that the 
> > physical network and interfaces are a shared resource: low level failures 
> > or misconfiguration at (say) Level 2, may still knockout the ACP as well as 
> > the data-plane.  Some brief words on this would not go amiss.  This could 
> > well be in s4.
> > 
> > s2, para 2: There are several instances in the terminology definitions that 
> > are confusing before the term has been fully introduced later (and in some 
> > cases even then, e.g., the cryptic reference to 'paragraph 21' in the ACP 
> > address definition.)  This should be cleared up.  Notes are given in the 
> > Nits/Editorial comments below,
> > 
> > s4, "ACP4", also s6.8.2:
> >> Clients of the ACP MUST
> >>NOT be tied to a particular application or transport protocol.
> > 
> > It may be that I don't understand the problem, but the communication 
> > between the ACP nodes seems to be tied to the secure channels.  
> 
> Yes, but those are IPv6-in-something channels, that being the nature of a VRF.
> So anything that runs over IPv6 is OK. (I'm not sure that this MUST NOT
> actually matters: once we know it's an IPv6 channel, do we care?)
> 
> > I am not sure how this is compatible with the any transport protocol 
> > requirement.  There doesn't seem to be any further explanation of how this 
> > requirement is fufilled.  This is linked to he means that is not specified 
> > by which the ACP address TLS connections are connected to the secure 
> > channels.  This may be because I don't understand the problem
> > 
> > s6.1.1:  RFC 5280 discusses the option of leaving the subjectName blank if 
> > the subjectAltName is present.  What would we expect to find in the 
> > subjectName field of the ACP Domain cert?
> > 
> > s6.1.1:  I don't understand where the routing-subdomain element is
> > carried.  routing-subdomain is a top level production in the ABNF that
> > isn't referenced in the rest of the ABNF and a separate example is
> > given.  Is the intention that the subjectAltName would consist of a
> > sequence of two rfc822names as allowed by the X.509 syntax if the
> > routing-subdomain is required?
> > 
> > s6.1.3: I don't understand why the EST renewal server address has to (or, 
> > at least, might) be configured into all ACP nodes when the EST server 
> > announces itself with M_FLOOD messages.  For one thing it goes (further) 
> 

Re: [Gen-art] Genart last call review of draft-ietf-teas-rsvp-ingress-protection-13

[Huaimo Chen]

Hi Robert,

Thank you very much for your time and valuable comments.
Answers to them are inline below with prefix [HC].
Would you mind reviewing them to see if they address the issues?

Best Regards,
Huaimo
-Original Message-
From: Robert Sparks [mailto:rjspa...@nostrum.com] 
Sent: Wednesday, February 21, 2018 12:20 PM
To: gen-art@ietf.org
Cc: i...@ietf.org; t...@ietf.org; 
draft-ietf-teas-rsvp-ingress-protection@ietf.org
Subject: Genart last call review of draft-ietf-teas-rsvp-ingress-protection-13

Reviewer: Robert Sparks
Review result: Not 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-teas-rsvp-ingress-protection-13
Reviewer: Robert Sparks
Review Date: 2018-02-21
IETF LC End Date: 2018-03-01
IESG Telechat date: 2018-03-08

 Summary: Not Ready for publication as an Experimental RFC

I found this document hard to read. I encourage a significant editorial pass 
that focuses on presenting the core ideas early, and simplifies the language 
used throughout the document.
[HC] We have presented the core ideas early and simplify the language used in
the document accordingly.


Major Issues:

1) The IANA considerations section is unclear. You ask IANA to put something in 
"Class Names, Class Numbers, and Class Types" at 
.
But there is no registry with that title on that page. (Nor is there a registry 
with a structure matching the row you are asking IANA to add.) Did you mean the 
registry at 
?
[HC] Yes. You are right. We have corrected it in the document. 


If so, the number you are suggesting is in a "Reserved for Private Use" range.
If that _was_ your target, the structure of your requested record does not 
match the structure of the existing registry. Please clarify.
[HC] We are considering a new C-Type under the existing Protection Class. 
The related text has be updated accordingly as below:
Upon approval of this document, IANA is requested to assign a new
Class Type or C-Type under Class Number 37 and Class Name PROTECTION
located at , as follows:

Value Description   Reference
- ---   -
  4Type 4 INGRESS_PROTECTION   This Document


The instructions to IANA for what to do when this document moves to the 
standards track are inappropriate. You can say that you anticipate that the 
future document that moves the idea to the standard track expects to create a 
new registry under rsvp-te-parameters, but this document cannot instruct IANA 
to do so.
[HC] We have revised the text according to your suggestion as below:
It is anticipated that the future document that moves the idea to the 
standard track expects IANA to create and maintain a new registry under
PROTECTION object class, Class Number 37, C-Type 4. Initial values for 
the registry are given below. The future assignments are to be made through 
IETF Review.


2) "After one approach is selected, the document SHOULD become proposed 
standard." is an innappropriate use of SHOULD, and doesn't correctly reflect 
the process that would be followed in any case. You could, instead, say "After 
one approach is selected, a document revising the ideas here to reflect that 
selection and any other items learned from the experiment is expected to be 
submitted for publication on the standards track."
[HC] We have updated the text accordingly as below:
After one approach is selected, the document will be revised 
to reflect that selection and any other items learned from 
the experiment. The revised document is expected to be submitted 
for publication on the standards track.


3) It is unclear until you get to section 5 (11 pages into the document) which 
elements provide and which elements consume the information in the proposed new 
object. The document is inconsistent about which messages the object can/should 
appear in. Moving the overview of behavior earlier in the document would help.
Simplifying the description of that behavior will help more. Making the other 
sections consistent with what that overview describes is necessary.
[HC] We have corrected the inconsistency and updated the document according to 
your suggestions.


Minor Issues:

a) It is not clear what the difference between source-detect and 
backup-source-detect really are (I agree with the comments in the rtgdir review 
on these sections). In section 2.1, where you say "reliably detect", do you 
really mean "verify"? The detection has already been 

Re: [Gen-art] Gen-art LC Review of draft-ietf-anima-autonomic-control-plane-13

[Brian E Carpenter]

Replying as a protagonist -

First thanks for the really thorough review with many good points.

Now a few replies in-line:

On 28/02/2018 15:24, Elwyn Davies wrote:
> 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-anima-autonomic-control-plane-13.txt
> Reviewer: Elwyn Davies
> Review Date: 2016/02/27
> IETF LC End Date:  2016/02/26
> IESG Telechat date: (if known) -
> 
> Summary:  Not ready.  There are a number of minor issues and a host of nits 
> and editorial fixes needed.  I would also consider that the expected status 
> (expeimental vs standards track) ought to be discussed on account of the 
> areas where it is incomplete (e.g., incompleteness of the key Intent 
> mechanism).

An Intent mechanism is not required to build and operate the ACP, and if
the draft gives that impression, it needs to be fixed.

> 
> Major issues:
> I am sure this has been considered elsewhere, but the amount of future work 
> and areas where operation might discover problems indicates to me that maybe 
> this should be an experimental proposal rather than standards track.

It's chartered as standards track and other drafts have a normative
dependency on it. So changing the intended status would be very
problematic. Of course it's a judgment call, but there's nothing
dubious that it depends on - ULAs, IPSEC, RPL, VRF functionality,
in fact all the normative references except GRASP and BRSKI are well
established. (GRASP has a mutual normative reference to this document,
and is already in the RFC Editor queue; BRSKI is not out of the
WG yet, so is likely to become a MISSREF.)

Yes, I'd be happier if I had running code for the ACP, but as far as
I know that isn't a requirement for Proposed Standard.
 
> Minor issues:
> Clarity regarding limitations of the ACP approach:The document is 
> relentlessly positive about the ACP approach.  Clearly certain problems will 
> not allow the ACP to function.  For example it implies that the physical 
> network and interfaces are a shared resource: low level failures or 
> misconfiguration at (say) Level 2, may still knockout the ACP as well as the 
> data-plane.  Some brief words on this would not go amiss.  This could well be 
> in s4.
> 
> s2, para 2: There are several instances in the terminology definitions that 
> are confusing before the term has been fully introduced later (and in some 
> cases even then, e.g., the cryptic reference to 'paragraph 21' in the ACP 
> address definition.)  This should be cleared up.  Notes are given in the 
> Nits/Editorial comments below,
> 
> s4, "ACP4", also s6.8.2:
>> Clients of the ACP MUST
>>NOT be tied to a particular application or transport protocol.
> 
> It may be that I don't understand the problem, but the communication between 
> the ACP nodes seems to be tied to the secure channels.  

Yes, but those are IPv6-in-something channels, that being the nature of a VRF.
So anything that runs over IPv6 is OK. (I'm not sure that this MUST NOT
actually matters: once we know it's an IPv6 channel, do we care?)

> I am not sure how this is compatible with the any transport protocol 
> requirement.  There doesn't seem to be any further explanation of how this 
> requirement is fufilled.  This is linked to he means that is not specified by 
> which the ACP address TLS connections are connected to the secure channels.  
> This may be because I don't understand the problem
> 
> s6.1.1:  RFC 5280 discusses the option of leaving the subjectName blank if 
> the subjectAltName is present.  What would we expect to find in the 
> subjectName field of the ACP Domain cert?
> 
> s6.1.1:  I don't understand where the routing-subdomain element is
> carried.  routing-subdomain is a top level production in the ABNF that
> isn't referenced in the rest of the ABNF and a separate example is
> given.  Is the intention that the subjectAltName would consist of a
> sequence of two rfc822names as allowed by the X.509 syntax if the
> routing-subdomain is required?
> 
> s6.1.3: I don't understand why the EST renewal server address has to (or, at 
> least, might) be configured into all ACP nodes when the EST server announces 
> itself with M_FLOOD messages.  For one thing it goes (further) against 
> automicity.
> 
> s6.7.x, Security algorithm agility?:  Each of the options specifies a
> MTI, minimum (in today's tems) capability set of cyypto algorithms. It
> is not clear (to me) how this will be adapted if and when these
> algorithms are no longer adequately secure.  Some words on ths may be
> necessary.
> 
> s9.1, "Network Partition":  I am not sure I believe the story on partition - 
> It seems possinle that one of the segments could be left 

Re: [Gen-art] [Hipsec] Genart last call review of draft-ietf-hip-rfc4423-bis-18

[Robert Moskowitz]

Mail folder problems.  I will be catching up with all of this starting 
Friday (Purim tonight and tomorrow).


Bob

On 02/18/2018 12:33 AM, Joel Halpern wrote:

Reviewer: Joel Halpern
Review result: Ready with Nits

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-hip-rfc4423-bis-18
Reviewer: Joel Halpern
Review Date: 2018-02-17
IETF LC End Date: 2018-02-26
IESG Telechat date: Not scheduled for a telechat

Summary: This document is ready for publication as an Informational RFCs.
  The following comments may be useful for the authors to consider.

Major issues: N/A

Minor issues:
 In the table in section 2.2 (Terms specific to this and other HIP
 documents) the Host Identity Hash is defined as "The cryptographic hash
 used in creating the Host Identity Tag from the Host Identity."  I am
 pretty sure the last word should be Identifier, not Identity,, which
 matches the meanings and the usage in the following term.

 In section 4.1 second paragraph, it seems odd to refer to the
 public-private key pair as the structure of the abstract Host Identity.
 Given that the earlier text refers to the Public key as the Host
 Identifier, I am not sure how you want to refer to the public/private key
 pair.  But I do not think it "is" the structure of the Host Identity.

 In the section 4.4 discussion of locally scoped identifier (LSI), it
 appears that applications need to be modified to use this.  Reading between
 the lines of the stack architecture, the actual advantage of using HIP with
 LSIs is that the application changes can be restricted to whatever
 indication is to be used that the stack is to use HIP, rather than changing
 the places that use sockaddrs, etc.  But this is not clearly stated here.

 In section 5.1 paragraph 3, the text talks about a connecting client not
 specifying a responder identifier (HIP Opportunistic mode) in order to
 enable load balancing.  I think the text would be helped by an example of
 how an initiator might know to do this, rather than just not using HIP.
 Also, it would be good if the text was explicit as to whether or not there
 was a way to support load balancing / multi servers without either using a
 shared identity or sacrificing security by using Opportunistic HIP.

 Given that section 5 is titled "New Stack Architecture", I think it would
 be helpful if the section were explicit as to where the HIP logic lives
 relative to the IP and UDP/TCP portions of the host stack.  This would help
 the reader have the right model for interpreting section 6.2 and 8.1.

Nits/editorial comments:
 Section 4.2 third sentence "It is possible to for ..." should be "It is
 possible for ..."


___
Hipsec mailing list
hip...@ietf.org
https://www.ietf.org/mailman/listinfo/hipsec



___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] R: Genart telechat review of draft-ietf-l2sm-l2vpn-service-model-08

[Joel M. Halpern]

Further comments in line, marked  ...  as some mail readers 
mangle the inclusion marking.
As a reminder, please work with your chair and sponsoring AD to 
determine when to submit changes.


Yours,
Joel

On 2/28/18 6:22 AM, Fioccola Giuseppe wrote:

Hi Joel,
Thanks for your detailed review! It is very useful.
My answers inline tagged as [GF]

Best Regards,

Giuseppe

-Messaggio originale-
Da: Joel Halpern [mailto:j...@joelhalpern.com]
Inviato: domenica 25 febbraio 2018 02:00
A: gen-art@ietf.org
Cc: l...@ietf.org; i...@ietf.org; 
draft-ietf-l2sm-l2vpn-service-model@ietf.org
Oggetto: Genart telechat review of draft-ietf-l2sm-l2vpn-service-model-08

Reviewer: Joel Halpern
Review result: On the Right Track

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 wait for direction from your document shepherd or AD before 
posting a new version of the draft.

For more information, please see the FAQ at

.

Document: draft-ietf-l2sm-l2vpn-service-model-08
Reviewer: Joel Halpern
Review Date: 2018-02-24
IETF LC End Date: 2018-03-26
IESG Telechat date: 2018-04-05

Summary: Given the number of Major and minor issues, this document is not yet 
ready for publication as a Proposed Standard RFC.

Major:
 Introduction: The phrasing of "an abstract model", "this model is not a
 configuration model..." creates some confusion in the reader as to whether
 this model represent the current state of service deliveyr, the desired
 state of service delivery (which would drive configuration) or both.
 Please clarify.

[GF]: Ok I understand and we can clarify this point in a new revision. This 
model is used to describe service intent or service requirements and 
characteristic associated with connectivity service. Consider that also in RFC 
8299 (L3SM) there is the same phrasing.


Thank you.  I think clarifying this will help the reader. 



 The "valid-provider-identifiers' distinguish between cloud-identifier and
 remote-carrier-identifier.  It i unclear why the VPN service provider
 should know or care whether the remote provider he is connecting with is a
 cloud provider, and another L2 service provider, or both.  And if it is
 both, which identifier should be used.

[GF]: Remote-carrrier-identifier is used in the NNI case, see the code within 
YANG module:
“
 leaf remote-carrier-name {
   when "derived-from-or-self(../../../site-vpn-flavor,"+
 "'l2vpn-svc:site-vpn-flavor-nni')" {
 description
   "Relevant when Site vpn flavor is
   site-vpn-flavor-nni.";
   }

”
[GF]: In the NNI case, the current VPN Service provider can connect to another 
L2VPN or Data Center network or Cloud Provider’s network. Please also see 
section 5.16 for NNI support details.
You are right, the VPN service provider doesn’t  care whether the remote 
provider is a cloud provider or L2VPN service provider. So remote carrier-name 
doesn’t need to distinguish cloud provider or L2VPN service provider, if you 
believe we should distinguish we can remove remote carrier name, we think it 
add complexity and note that remote carrier name is an optional parameter. 
Regarding cloud-identifier defined within “valid-provider-identifiers”, 
cloud-identifier is only applied to public cloud or internet access, while 
remote-carrier-name can be referred to private cloud/data center or another 
L2VPN. That’s why we use cloud-identifier within cloud-access.


 I did see the indirect references, that basically make these name 
lists a constraint on what values can be used in the other parts of the 
model.  That is effective.  What is unclear is why you have the 
different kinds of identifiers, as the distinctions are not very clear. 





 Also, it is very unclear how these identifiers will be used.  They
 presumably are names of something.  But of what?  As known to whom?
 Derived from where?  I do not see how a provider / customer pair using this
 model will know what values to use for this.

[GF]: We think one is name of the public cloud or internet access, the other is 
carrier name, they are different. We assume in this model to use “cloud access” 
to get access to public cloud or internet, we use “NNI” to get access to 
private cloud, data center or another L2VPN, therefore Cloud identifier should 
be known by both the current L2VPN Service provider and the customer. Remote 
Carrier name in NNI case should be known by the current L2VPN service provider 
it is connecting.


The point I was trying to get at, and probably muddled, is that the 
name a customer uses for some third party may not be the same as the 
name the service providers uses (although they will be similar.  Is 
Ericsson A.B. the same or different from Ericsson Inc. or 

Re: [Gen-art] Genart early review of draft-ietf-opsawg-ipfix-bgp-community-04

[Joel Halpern Direct]

I am having trouble reconciling two of your comments.
In you rlast email you said that this is for "planed communities 
represent the groups of customers peers an geographical and topological 
related information".  Planned communities is presumably a new behavior, 
not existing behavior.


In this email you say that these are "already defined BGP communities".

You reference RFC 4384, which talks about several kinds of communities. 
maybe you intend the regional or national communities mentioned as being 
possible, but not defined, in that document.  This document's 
descriptions do not align well enough with RFC 4384 for me to say.


Let's be clear.  The working group asked for an early review.  The WG 
now has my review, indicating that this document is unclear in multiple 
regards and could use improvement.


It is now up to the WG and the chairs.
Yours,
Joel

On 2/28/18 6:22 AM, li zhenqiang wrote:

Hi Joel,

This is not for one operator, instead it is a common practice. Please 
refer to RFC4384 and comments from Thomas who are from Swisscom.


One clarification for this doc is it is not to introduce any new BGP 
communities but to report the already defined BGP communities related to 
a traffic flow through IPFIX, thus the IPFIX collector can analyze the 
traffic in BGP community granularity without running BGP protocol.


BGP community is a transitive attibute, thus the exporter can report all 
the communities carried in the matching route entry, unless some BGP 
communities are filtered by some routers.


Sure I can add some text in the doc to say the proper processing of the 
exporter, something like what I said in the previous mail, do you think 
it is ok and enough?
  When the exporter, i.e. router, receives the templete to report 
the communities, the exporter gets the information through BGP lookup 
using the corresponding source or destination IP of a traffic flow.


Thank you for your comments.

Best Regards,
Zhenqiang Li

li_zhenqi...@hotmail.com

*From:* Joel M. Halpern 
*Date:* 2018-02-28 10:13
*To:* li zhenqiang ; Dongjie
(Jimmy) ; gen-art@ietf.org

*CC:* draft-ietf-opsawg-ipfix-bgp-community@ietf.org
; opsawg

*Subject:* Re: Genart early review of
draft-ietf-opsawg-ipfix-bgp-community-04
Is this for one operator (still important, but not necessarily for
standardization) or are there several operators who have expressed
interest in this?
Yes, we do proactive standards.  But the IDR group, for example, tends
to be very careful to see if interest is reflected in implementation.
In this case, given that what is proposed is a completely different use
of the BGP communities, I think at least more clarity that this is only
expected to be used for communities that match the purpose, and of how
and why the vendors would implement the router-side logic.
To get back to the points I made in the review:
1) The document needs to be much clearer that it is about new
communities whcih are expected to be defined for this use.  It needs to
be clear if this is expected to be applied to communities put on by
other AS, or only to communities provided by routers of the collecting
AS.  The later leads to understandable configuration.  The former leads
to questions about hos the meaning will be known.
2) The document needs to be clear and explicit about what processing it
is expecting the router to provide, and how much configuration is
needed
to get the right things to happen.
Yours,
Joel
On 2/27/18 8:54 PM, li zhenqiang wrote:
 > Hi Joel,
 >
 > This is Zhenqiang Li from China Mobile. The purpose of this doc
is not
 > to report the well-known communities, but the operator planed
 > communities represent the groups of the customers, peers,
 > the geographical and topological related information as stated in
 > RFC4384, which is a common practice and also used in our field
network.
 >
 > When the exporter, i.e. router, receives the templete to report the
 > communities, the exporter gets the information through BGP lookup
using
 > the corresponding source or destination IP of a traffic flow. The
 > procedure for the exporter to get the community informaiton of a
traffic
 > flow is the same as it gets the AS information.
 >
 > Best Regards,
 > Zhenqiang Li
 >

 > li_zhenqi...@hotmail.com
 >
 > *From:* Joel M. Halpern 
 > *Date:* 2018-02-12 00:37
 > *To:* Dongjie (Jimmy) 

Re: [Gen-art] New draft of SWIMA -03

[Dan Romascanu]

Hi Charles,

Thank you for updating me on the new version, for your responsiveness and
for addressing my comments. I believe that the document is now Ready from
the Gen-ART point of view. I suggest that you continue to work with the
authors of the SACM terminology document in order to reach consistency on
terminology, as discussed during our exchange of messages.

Regards,

Dan



On Wed, Feb 28, 2018 at 3:14 PM, Schmidt, Charles M. 
wrote:

> Hi Dan,
>
> I wanted to send a quick note that a new draft of the SACM SWIMA
> specification has been uploaded. This draft includes the edits we
> discussed. Please let me know if you have any additional comments. Thanks
> again for the feedback - it really helped the specification.
>
> Thanks,
> Charles
>
> > -Original Message-
> > From: Dan Romascanu [mailto:droma...@gmail.com]
> > Sent: Thursday, February 22, 2018 3:35 AM
> > To: Schmidt, Charles M. 
> > Cc: gen-art@ietf.org; draft-ietf-sacm-nea-swima-patnc@ietf.org;
> > i...@ietf.org; s...@ietf.org
> > Subject: Re: Genart telechat review of draft-ietf-sacm-nea-swima-
> patnc-02
> >
> > Hi Charles.
> >
> > This paragraph is very reasonable and informative for all audiences.
> >
> >
> > Thanks again.
> >
> >
> > Dan
> >
> >
> >
> > On Thu, Feb 22, 2018 at 12:23 AM, Schmidt, Charles M.
> >  > wrote:
> >
> >
> >   Hi Dan,
> >
> >
> >
> >   Thanks for your response. I agree on all points. I'll add the
> following
> > paragraph to the end of the introduction:
> >
> >
> >
> >   "Part of the motivation for the development of SWIMA was to
> > support the IETF’s Security Automation and Continuous Monitoring (SACM)
> > architecture. More details about SWIMA’s role in SACM appear in  > target=”Relationship”/>. However, SWIMA has no dependencies on any part
> > of SACM and is usable wherever the NEA architecture is employed."
> >
> >
> >
> >   Does this seem reasonable? (I agree that we need to address the
> > expectation that people will have to see SACM mentioned in a SACM WG
> > document, but I also want to make very sure that people don't see SWIMA
> as
> > only being applicable in that context.)
> >
> >
> >
> >   Thanks,
> >
> >   Charles
> >
> >
> >
> >   From: Dan Romascanu [mailto:droma...@gmail.com
> >  ]
> >   Sent: Wednesday, February 21, 2018 4:11 PM
> >   To: Schmidt, Charles M.  >  >
> >   Cc: gen-art@ietf.org  ;
> draft-ietf-sacm-nea-
> > swima-patnc@ietf.org  > patnc@ietf.org> ; i...@ietf.org  ;
> s...@ietf.org
> > 
> >   Subject: Re: Genart telechat review of draft-ietf-sacm-nea-swima-
> > patnc-02
> >
> >
> >
> >   Hi Charles,
> >
> >   Thank you for your response and for addressing my comments. I feel
> > that they are largely addressed by your proposed resolution. See also
> in-line.
> >
> >   Regards,
> >
> >   Dan
> >
> >
> >
> >   On Wed, Feb 21, 2018 at 10:50 PM, Schmidt, Charles M.
> >  > wrote:
> >
> >   Hello,
> >
> >   Thanks a bunch for the comments. I'm glad that you feel
> that
> > it looks like a solid contribution.
> >
> >   With regard to your feedback, I have developed wording to
> > address both your major concerns and wanted to run it by you:
> >
> >   ---
> >   With regard to the lack of mention of SACM, I agree that it
> > was an oversight not to mention it in the Relationship to Other Standards
> > section. I propose adding the following paragraph at the end of that
> section:
> >
> >   "The NEA architecture is intended to support a broad range
> > of activities and, as such, might be employed by other specifications.
> For
> > example, requirement T-001 in the SACM Requirements document (RFC
> > 8248) notes that NEA can support data collection from endpoints within
> the
> > broader SACM architecture. (Other parts of the NEA architecture, which
> > SWIMA uses, meet the other SACM data transport requirements.) In the
> > SACM architecture, a SWIMA-PV corresponds to a “SACM Collector” and a
> > SWIMA-PC is a “SACM Internal Collector”. In the SACM architecture, the
> > SWIMA specification can support activities relating to software inventory
> > collection. Specifically, SWIMA supports the SACM “Endpoint Posture
> > Attribute Value Collection” use case (section 2.1.3 or RFC 7632) by
> describing
> > a collection mechanism that enables event driven, scheduled, and ad-hoc
> > data collection of software inventory information. SWIMA’s flexibility
> with
> > regard to the format of inventory data records means that it is
> compatible
> > with virtually any data format that implements SACM’s “Define, Publish,
> > Query, and 

[Gen-art] New draft of SWIMA -03

[Schmidt, Charles M.]

Hi Dan,

I wanted to send a quick note that a new draft of the SACM SWIMA specification 
has been uploaded. This draft includes the edits we discussed. Please let me 
know if you have any additional comments. Thanks again for the feedback - it 
really helped the specification.

Thanks,
Charles

> -Original Message-
> From: Dan Romascanu [mailto:droma...@gmail.com]
> Sent: Thursday, February 22, 2018 3:35 AM
> To: Schmidt, Charles M. 
> Cc: gen-art@ietf.org; draft-ietf-sacm-nea-swima-patnc@ietf.org;
> i...@ietf.org; s...@ietf.org
> Subject: Re: Genart telechat review of draft-ietf-sacm-nea-swima-patnc-02
> 
> Hi Charles.
> 
> This paragraph is very reasonable and informative for all audiences.
> 
> 
> Thanks again.
> 
> 
> Dan
> 
> 
> 
> On Thu, Feb 22, 2018 at 12:23 AM, Schmidt, Charles M.
>  > wrote:
> 
> 
>   Hi Dan,
> 
> 
> 
>   Thanks for your response. I agree on all points. I'll add the following
> paragraph to the end of the introduction:
> 
> 
> 
>   "Part of the motivation for the development of SWIMA was to
> support the IETF’s Security Automation and Continuous Monitoring (SACM)
> architecture. More details about SWIMA’s role in SACM appear in  target=”Relationship”/>. However, SWIMA has no dependencies on any part
> of SACM and is usable wherever the NEA architecture is employed."
> 
> 
> 
>   Does this seem reasonable? (I agree that we need to address the
> expectation that people will have to see SACM mentioned in a SACM WG
> document, but I also want to make very sure that people don't see SWIMA as
> only being applicable in that context.)
> 
> 
> 
>   Thanks,
> 
>   Charles
> 
> 
> 
>   From: Dan Romascanu [mailto:droma...@gmail.com
>  ]
>   Sent: Wednesday, February 21, 2018 4:11 PM
>   To: Schmidt, Charles M.   >
>   Cc: gen-art@ietf.org  ; draft-ietf-sacm-nea-
> swima-patnc@ietf.org  patnc@ietf.org> ; i...@ietf.org  ; s...@ietf.org
> 
>   Subject: Re: Genart telechat review of draft-ietf-sacm-nea-swima-
> patnc-02
> 
> 
> 
>   Hi Charles,
> 
>   Thank you for your response and for addressing my comments. I feel
> that they are largely addressed by your proposed resolution. See also in-line.
> 
>   Regards,
> 
>   Dan
> 
> 
> 
>   On Wed, Feb 21, 2018 at 10:50 PM, Schmidt, Charles M.
>  > wrote:
> 
>   Hello,
> 
>   Thanks a bunch for the comments. I'm glad that you feel that
> it looks like a solid contribution.
> 
>   With regard to your feedback, I have developed wording to
> address both your major concerns and wanted to run it by you:
> 
>   ---
>   With regard to the lack of mention of SACM, I agree that it
> was an oversight not to mention it in the Relationship to Other Standards
> section. I propose adding the following paragraph at the end of that section:
> 
>   "The NEA architecture is intended to support a broad range
> of activities and, as such, might be employed by other specifications. For
> example, requirement T-001 in the SACM Requirements document (RFC
> 8248) notes that NEA can support data collection from endpoints within the
> broader SACM architecture. (Other parts of the NEA architecture, which
> SWIMA uses, meet the other SACM data transport requirements.) In the
> SACM architecture, a SWIMA-PV corresponds to a “SACM Collector” and a
> SWIMA-PC is a “SACM Internal Collector”. In the SACM architecture, the
> SWIMA specification can support activities relating to software inventory
> collection. Specifically, SWIMA supports the SACM “Endpoint Posture
> Attribute Value Collection” use case (section 2.1.3 or RFC 7632) by describing
> a collection mechanism that enables event driven, scheduled, and ad-hoc
> data collection of software inventory information. SWIMA’s flexibility with
> regard to the format of inventory data records means that it is compatible
> with virtually any data format that implements SACM’s “Define, Publish,
> Query, and Retrieve Security Automation Data” (section 2.1.1 in RFC 7632).
> This is just one example of how SWIMA can support broader security
> solution standards. Note that, while SWIMA can support these SACM use
> cases, SWIMA has no dependencies upon the SACM architecture or any
> other context in which NEA might reasonably be applied."
> 
> 
> 
>   This looks good. I would also suggest to add a sentence or paragraph
> describing for short the relationship to SACM in the Introduction. As this is 
> a
> SACM WG document, some readers would probably expect to see this
> relationship mentioned earlier than in Section 9.
> 
> 
> 
> 
>   I believe this addresses most of the 

[Gen-art] R: Genart telechat review of draft-ietf-l2sm-l2vpn-service-model-08

[Fioccola Giuseppe]

Hi Joel,
Thanks for your detailed review! It is very useful.
My answers inline tagged as [GF]

Best Regards,

Giuseppe

-Messaggio originale-
Da: Joel Halpern [mailto:j...@joelhalpern.com] 
Inviato: domenica 25 febbraio 2018 02:00
A: gen-art@ietf.org
Cc: l...@ietf.org; i...@ietf.org; 
draft-ietf-l2sm-l2vpn-service-model@ietf.org
Oggetto: Genart telechat review of draft-ietf-l2sm-l2vpn-service-model-08

Reviewer: Joel Halpern
Review result: On the Right Track

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 wait for direction from your document shepherd or AD before 
posting a new version of the draft.

For more information, please see the FAQ at

.

Document: draft-ietf-l2sm-l2vpn-service-model-08
Reviewer: Joel Halpern
Review Date: 2018-02-24
IETF LC End Date: 2018-03-26
IESG Telechat date: 2018-04-05

Summary: Given the number of Major and minor issues, this document is not yet 
ready for publication as a Proposed Standard RFC.

Major:
Introduction: The phrasing of "an abstract model", "this model is not a
configuration model..." creates some confusion in the reader as to whether
this model represent the current state of service deliveyr, the desired
state of service delivery (which would drive configuration) or both. 
Please clarify.

[GF]: Ok I understand and we can clarify this point in a new revision. This 
model is used to describe service intent or service requirements and 
characteristic associated with connectivity service. Consider that also in RFC 
8299 (L3SM) there is the same phrasing.

The "valid-provider-identifiers' distinguish between cloud-identifier and
remote-carrier-identifier.  It i unclear why the VPN service provider
should know or care whether the remote provider he is connecting with is a
cloud provider, and another L2 service provider, or both.  And if it is
both, which identifier should be used.

[GF]: Remote-carrrier-identifier is used in the NNI case, see the code within 
YANG module:
“
leaf remote-carrier-name {
  when "derived-from-or-self(../../../site-vpn-flavor,"+
"'l2vpn-svc:site-vpn-flavor-nni')" {
description
  "Relevant when Site vpn flavor is
  site-vpn-flavor-nni.";
  }

”
[GF]: In the NNI case, the current VPN Service provider can connect to another 
L2VPN or Data Center network or Cloud Provider’s network. Please also see 
section 5.16 for NNI support details.
You are right, the VPN service provider doesn’t  care whether the remote 
provider is a cloud provider or L2VPN service provider. So remote carrier-name 
doesn’t need to distinguish cloud provider or L2VPN service provider, if you 
believe we should distinguish we can remove remote carrier name, we think it 
add complexity and note that remote carrier name is an optional parameter. 
Regarding cloud-identifier defined within “valid-provider-identifiers”, 
cloud-identifier is only applied to public cloud or internet access, while 
remote-carrier-name can be referred to private cloud/data center or another 
L2VPN. That’s why we use cloud-identifier within cloud-access.

Also, it is very unclear how these identifiers will be used.  They
presumably are names of something.  But of what?  As known to whom? 
Derived from where?  I do not see how a provider / customer pair using this
model will know what values to use for this.  

[GF]: We think one is name of the public cloud or internet access, the other is 
carrier name, they are different. We assume in this model to use “cloud access” 
to get access to public cloud or internet, we use “NNI” to get access to 
private cloud, data center or another L2VPN, therefore Cloud identifier should 
be known by both the current L2VPN Service provider and the customer. Remote 
Carrier name in NNI case should be known by the current L2VPN service provider 
it is connecting.

Even if the intention is that
these be names made available by the provider by external means, the YANG
model needs to say that if it is to be usable. I did eventually find some
explanation in section 5.15.  At the very least a forward reference is
needed.  I think more explanation of what these things names would also
help.

[GF]: Ok

The use of different sets of what read like service types (is cloud access
a service type?  Is remote-access a service type?) and the use of similar
but not the same terminology between provider descriptions, service types,
and service topologies, leaves the reader VERY confused.  Please, do not
use the same term for kinds of providers, kinds of services, and kinds of
topologies unless the names are fully congruent (which they currently are
not.)

[GF]: No, the service-type is only referred