Re: [Gen-art] Genart last call review of draft-ietf-mtgvenue-iaoc-venue-selection-process-11

[Eliot Lear]

Ok.  I'll push an update based on these changes in the next few days,
barring additional comments.


On 30.01.18 17:02, Dan Romascanu wrote:
>
>
>
> On Tue, Jan 30, 2018 at 5:54 PM, Alissa Cooper  > wrote:
>
>
> > On Jan 29, 2018, at 1:12 PM, Pete Resnick
> > wrote:
> >
> >
> >> 8. Section 4:
> >>
> >> 'It is anticipated that
> >>   those roles will evolve.  The IASA is responsible for keeping the
> >>   community informed in this regard, and MAY do so without updating
> >>   this memo.'
> >>
> >> I would be a little concerned if some of the key roles would
> change without
> >> this document being updated. I understand the need to be
> flexible, but we need
> >> to put some limits. Maybe at least emphasize the need to inform
> the community
> >> by a MUST. For example:
> >>
> >> 'It is anticipated that
> >>   those roles will evolve.  The IASA MUST keep the
> >>   community informed in this regard, and MAY do so without updating
> >>   this memo.'
> >
> > I don't think the MUST significantly changes the meaning, so I'm
> ambivalent about the change. Since this text was put in to address
> a comment in AD Evaluation, I'm inclined to hear from Alissa.
>
> Perhaps the concern could be addressed by saying “without first
> updating this memo”? The point I raised is that this document
> shouldn’t gate the ability for the roles to change, but certainly
> if they do change the document should be updated (or obsoleted by
> a new document) to match the reality.
>
> Thanks,
> Alissa
>
>
>
> That would be fine with me.
>
> Regards,
>
> Dan
>



signature.asc
Description: OpenPGP digital signature
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Genart last call review of draft-ietf-mtgvenue-iaoc-venue-selection-process-11

[Dan Romascanu]

On Tue, Jan 30, 2018 at 5:54 PM, Alissa Cooper  wrote:

>
> > On Jan 29, 2018, at 1:12 PM, Pete Resnick 
> wrote:
> >
> >
> >> 8. Section 4:
> >>
> >> 'It is anticipated that
> >>   those roles will evolve.  The IASA is responsible for keeping the
> >>   community informed in this regard, and MAY do so without updating
> >>   this memo.'
> >>
> >> I would be a little concerned if some of the key roles would change
> without
> >> this document being updated. I understand the need to be flexible, but
> we need
> >> to put some limits. Maybe at least emphasize the need to inform the
> community
> >> by a MUST. For example:
> >>
> >> 'It is anticipated that
> >>   those roles will evolve.  The IASA MUST keep the
> >>   community informed in this regard, and MAY do so without updating
> >>   this memo.'
> >
> > I don't think the MUST significantly changes the meaning, so I'm
> ambivalent about the change. Since this text was put in to address a
> comment in AD Evaluation, I'm inclined to hear from Alissa.
>
> Perhaps the concern could be addressed by saying “without first updating
> this memo”? The point I raised is that this document shouldn’t gate the
> ability for the roles to change, but certainly if they do change the
> document should be updated (or obsoleted by a new document) to match the
> reality.
>
> Thanks,
> Alissa



That would be fine with me.

Regards,

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

Re: [Gen-art] Genart last call review of draft-ietf-mtgvenue-iaoc-venue-selection-process-11

[Alissa Cooper]

> On Jan 29, 2018, at 1:12 PM, Pete Resnick  wrote:
> 
> 
>> 8. Section 4:
>> 
>> 'It is anticipated that
>>   those roles will evolve.  The IASA is responsible for keeping the
>>   community informed in this regard, and MAY do so without updating
>>   this memo.'
>> 
>> I would be a little concerned if some of the key roles would change without
>> this document being updated. I understand the need to be flexible, but we 
>> need
>> to put some limits. Maybe at least emphasize the need to inform the community
>> by a MUST. For example:
>> 
>> 'It is anticipated that
>>   those roles will evolve.  The IASA MUST keep the
>>   community informed in this regard, and MAY do so without updating
>>   this memo.'
> 
> I don't think the MUST significantly changes the meaning, so I'm ambivalent 
> about the change. Since this text was put in to address a comment in AD 
> Evaluation, I'm inclined to hear from Alissa.

Perhaps the concern could be addressed by saying “without first updating this 
memo”? The point I raised is that this document shouldn’t gate the ability for 
the roles to change, but certainly if they do change the document should be 
updated (or obsoleted by a new document) to match the reality.

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

[Gen-art] Genart last call review of draft-ietf-bmwg-sdn-controller-benchmark-term-07

[Stewart Bryant]

Reviewer: Stewart Bryant
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-bmwg-sdn-controller-benchmark-term-07
Reviewer: Stewart Bryant
Review Date: 2018-01-30
IETF LC End Date: 2018-02-02
IESG Telechat date: Not scheduled for a telechat

Summary: Generally a well written document. The various comments I make are
mostly editorial with some on the fringe of being technical.

Major issues: None

Minor issues:
2.3.1.3. Asynchronous Message Processing Rate

Definition:
   The number responses to asynchronous messages (such as new flow
SB> That should be the number of responses per second.

Discussion:
   As SDN assures flexible network and agile provisioning, it is
   important to measure how many network events the controller can
   handle at a time. This benchmark is obtained by sending asynchronous
   messages from every connected Network Device at the rate that the
   controller processes (without dropping them).

SB> So what you are testing here is the control network and the
SB> controller. This is perhaps the only practical way to run the
SB> test, but it seems a pity that you do not deconvolve these
SB> two aspects of the test.
SB>
SB> I suppose this is really network Async Msg Proc rate rather than
SB> controller Async proc rate.
SB>
SB> We may get to this in the companion document, but doesn't there
SB> need to be some standardization of the event message to compare
SB> apple with apples over time?

Nits/editorial comments:

Abstract

   A mechanism for
   benchmarking the performance of SDN controllers is defined in the
   companion methodology document.
SB> It would be convenient to the reader to provide the reference to or name of
SB> the companion document

2.2.4. Number of Cluster nodes

Discussion:
   This parameter is relevant when testing the controller performance
   in clustering/teaming mode. The number of nodes in the cluster MUST
   be greater than 1.

SB> I see what you are saying, but you may wish to clarify that this
SB> constraint does not apply all the time. For example one of two nodes
SB> may start later than another, or fail, or maybe I worry over nothing here.

2.3. Benchmarking Terms

   This section defines metrics for benchmarking the SDN controller.
SB> Should that be controller(s)?

2.3.1.4. Reactive Path Provisioning Time

Definition:
   The time taken by the controller to setup a path reactively between
   source and destination node, defined as the interval starting with
   the first flow provisioning request message received by the
   controller(s), ending with the last flow provisioning response
   message sent from the controller(s) at it Southbound interface.

Discussion:
   As SDN supports agile provisioning, it is important to measure how
SB> Should that be When, rather that As since not all will support the feature.

2.3.2.1. Control Sessions Capacity

Measurement Units:
SB> Surely this should be in units of sessions?

2.3.2.2. Network Discovery Size

Measurement Units:

   N/A

SB> How can this be N/A surely it is a number of network units of various type.

2.3.2.3. Forwarding Table Capacity

2.3.3. Security

2.3.3.1. Exception Handling

Measurement Units:
   N/A

SB> Shouldn't that be as per base performance test specified in 2.3.1?
SB> or text similar to 2.3.3.2 UoM?

7. Security Considerations

   Security issues are not discussed in this memo.

SB> Whilst true, you do of course instrument various security related
SB> parameters

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

Re: [Gen-art] [FORGED] Genart telechat review of draft-gutmann-scep-08

[Peter Gutmann]

>However, there are some issues (mostly editorial) that I would like the
>authors to address.

One comment on this, I didn't write the original text so I'll try and
accommodate as much as possible, but in some cases I've had to guess at what
the original authors intended.  Also, the explanations for several of the
points raised in the questions is "it was like that when I got here".  So in
the following, when I respond with another question, it's because I'm not sure
myself what should go in there, and I'm welcoming any suggestions...

Another general point, because this has spent close to twenty years in draft
status, it's been a de facto standard for most of that time so there are
"standards-compliant" implementations that have been in use for more than a
decade based on the draft.  Because of this, I've had to be very careful to
avoid breaking things by introducing a MUST or MUST NOT after nearly two
decades of something not being a MUST.  This is why, in some places, there's a
SHOULD with strong hints rather than a MUST.

The primary goal for this was to make it bits-on-the-wire compatible (apart
from the unavoidable single DES + MD5 -> AES + SHA-2), and to minimise
(ideally not to have any) breakage with deployed code.  So there are places
where there are weasel-words ("we know you've been doing this for fifteen
years but you probably shouldn't any more"), and others where I've retained
text that I wouldn't have put in there if I'd been the one writting the doc.

>Q1:
>
>[Editing changes]

I've had a go at changing this, but no matter what I do just ends up as the
same wording shuffled around, I end up just moving bits from one location to
another (it's already gone through a number of re-wordings across different
drafts).  If there's a specific goal that you're aiming for with the changes I
can try and hit that, but I just ended up saying more or less the same thing
with different phrasing.

>Q2:
>
>Doesn’t the "While implementers are encouraged to…" sentence belong to the
>Security Considerations?

It's not a security consideration, unless I'm missing something it only
discusses functionality and interoperability issues.

>Q3:
>
>The text says:
>
>   "A CA MAY enforce any arbitrary policies and apply them to certificate
>   requests, and MAY reject any request."
>
>The "MAY reject any request" parts sounds unfinished. I assume it’s refers to
>cases where the client don’t support such arbitrary policies? If so, I suggest
>to explicitly say so.
>
>Currently it sounds like a generic CA-may-reject-any-request statement, which
>I assume is not what you intend to say :)

That's exactly what it's meant to say: "You can ask for anything you want, but
the CA isn't obligated to comply with your request".

(Also: "It was like that when I got here").

>Q4:
>
>As the text talks about certificate distribution, is this really a subsection
>to section 2.1?

"It was like that when I got here".  I can make it a non-subsection if it
reads better that way.

>Q5:
>
>The 4th paragraph contains a couple of SHOULDs. Is there a reason they can’t
>be MUST?

There are many ways to verify certs, those are just suggestions.  For example
they may be hardcoded into the client (that's actually not uncommon in SCADA
use), in which case there's nothing to verify.

>Q6:
>
>The 5th paragraph talks about how early versions of the draft used GET
>messages for all communication.
>
>The text also says:
>
>“If the remote CA supports it, any of the CMS-encoded SCEP messages SHOULD be
>sent via HTTP POST instead of HTTP GET.”
>
>If the remove CA supports what? HTTP POST?

Yes, fixed.

>Why SHOULD, and not MUST?

See the note about introducing breakage.

>If the client understands to use POST if GET fails, why can’t it use POST to
>begin with?

It was meant to say (subtly) "if you're seeing these problems then perhaps
it's time you updated your code".  I've changed the text to make this more
explicit:

  The solution to this problem is to update the implementation to use HTTP
  POST instead.

>In general, what is the reason for having this text about early versions of
>the draft? Backward compatibility with CAs that will only support GET?

Yes.  Not just CAs but major implementations like Microsoft's NDES.

>Q7:
>
>The title of the section talks about state transitions, but then the text
>says that the section contains examples.
>
>Is there a reference to the state machine(s) that are represented in the
>examples? OR, does the section define the state machine(s)?

"It was like that when I got here".  It's supposed to illustrate state
transitions, so it's both a diagram and an example of what's supposed to
happen.  I'm reluctant to start rewriting that to any extent because, well,
would you want to start poking around in there?

>Q8:
>
>The text says “previous editors” and “earlier editors”. Please pick one and
>use it in both places :)

It's actually "earlier authors", and it was deliberate, to distinguish between
the people who wrote it