Re: [Gen-art] Genart last call review of draft-ietf-6man-rfc6874bis-02

[Brian E Carpenter]

Roni,

Assuming "easy" means "ready", thank you!

Regards
   Brian Carpenter

On 24-Sep-22 19:31, Roni Even via Datatracker wrote:

Reviewer: Roni Even
Review result: 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-6man-rfc6874bis-??
Reviewer: Roni Even
Review Date: 2022-09-24
IETF LC End Date: 2022-09-26
IESG Telechat date: Not scheduled for a telechat

Summary:
The document is easy for publication as a standard track rfc

Major issues:

Minor issues:

Nits/editorial comments:





___
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-carpenter-rfced-iab-charter-05

[Brian E Carpenter]

Can somebody tell me how to insert that seriesNo="39" in kramdown?


Never mind. I found out by trial and error (seriesNo: "39").

Regards
   Brian
On 16-Feb-22 10:25, Brian E Carpenter wrote:

Pete,

Good catches, thanks.

Can somebody tell me how to insert that seriesNo="39" in kramdown?

Regards
 Brian Carpenter

On 16-Feb-22 09:08, Pete Resnick wrote:

[Sorry; resending from the proper From address.]

Oh, one other bit: In the  directive at the top of the XML, you
should add seriesNo="39" as an indicator to the RFC Editor to make sure
that this document is added to BCP 39, not create a new BCP number.

On 15 Feb 2022, at 14:02, Pete Resnick via Datatracker wrote:


Reviewer: Pete Resnick
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

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq> .

Document: draft-carpenter-rfced-iab-charter-05
Reviewer: Pete Resnick
Review Date: 2022-02-15
IETF LC End Date: 2022-03-07
IESG Telechat date: 2022-03-10

Summary: Looks fine, save one typo

Major issues: None

Minor issues: None

Nits/editorial comments: In section 2, change "(b) RFC Series and
IANA" to "(d) RFC Series and IANA"





___
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-carpenter-rfced-iab-charter-05

[Brian E Carpenter]

Pete,

Good catches, thanks.

Can somebody tell me how to insert that seriesNo="39" in kramdown?

Regards
   Brian Carpenter

On 16-Feb-22 09:08, Pete Resnick wrote:

[Sorry; resending from the proper From address.]

Oh, one other bit: In the  directive at the top of the XML, you
should add seriesNo="39" as an indicator to the RFC Editor to make sure
that this document is added to BCP 39, not create a new BCP number.

On 15 Feb 2022, at 14:02, Pete Resnick via Datatracker wrote:


Reviewer: Pete Resnick
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-carpenter-rfced-iab-charter-05
Reviewer: Pete Resnick
Review Date: 2022-02-15
IETF LC End Date: 2022-03-07
IESG Telechat date: 2022-03-10

Summary: Looks fine, save one typo

Major issues: None

Minor issues: None

Nits/editorial comments: In section 2, change "(b) RFC Series and
IANA" to "(d) RFC Series and IANA"





___
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-anima-asa-guidelines-04

[Brian E Carpenter]

Hi Thomas,

Thanks for the careful reading and review. I think we can deal
with all your comments without difficulty. Just two possible
discussion points in line below.

Regards
   Brian

On 07-Dec-21 03:58, Thomas Fossati via Datatracker wrote:

Reviewer: Thomas Fossati
Review result: Ready with Issues


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-asa-guidelines-??
Reviewer: Thomas Fossati
Review Date: 2021-12-06
IETF LC End Date: 2021-12-13
IESG Telechat date: Not scheduled for a telechat

Summary:

The document contains guidance for building ASAs.  It discusses
different kinds of requirements and their impact on the software
architecture.  It looks like an useful doc to have.

In general, the document reads very well, with the exception of Section
6 - see "Minor issues" below.

Major issues:

Minor issues:

In Section 6.3, I have followed the reference to
draft-peloso-anima-autonomic-function and I noticed that the content of
Section 6 has been transplanted nearly as-is from there.  So, to avoid
redundancy, I wonder whether that content should be given the same
treatment as you do in Section 7 WRT draft-ciavaglia-anima-coordination?
Or maybe you want to re-think the approach and have Section 7 do similar
copy from draft-ciavaglia-anima-coordination?  They are both
individual and expired draft after all so it's probably better doing the
latter.

I also wonder whether it is worth to spell out explicitly the fact that,
given ASAs may need to co-exist with the actual networking application,
they should be build to require minimal memory footprint &, in general,
use system resources with parsimony.  A related question is whether ASAs
require dedicated system resources in order to continue operating in a
busy system?



Generally we expect that ASAs will run at a much lower frequency than
any "production" workload in the node, so CPU load should not be a big
issue, but memory footprint in a constrained node is certainly a
concern. We tend to assume that ASAs will be mainly installed in
non-constrained devices, or that if they are in a constrained device,
they'll have a subset of functionality. Officially, we punted on that
issue - RFC8993 says "At a later stage, the ANIMA Working Group may
define a scope for constrained nodes with a reduced ANI and well-
defined minimal functionality."



Nits/editorial comments:

Section 2.

*  Repeatedly flood an objective to the AN, so that any ASA can

Expand "AN" on first use.

These threads should all either exit after their job is done, or
enter a wait state for new work, to avoid blocking others
unnecessarily.

"blocking others unnecessarily" is not what would typically happen,
maybe "to avoid wasting system resources" ?

[...] It
should also do whatever is required to avoid unnecessary resource
consumption, such as including an arbitrary wait time in each cycle
of the main loop.

I am not sure what "arbitrary wait time" refers to?  Is it a "sleep(n)"
at the end of each iteration of the main loop?  I think it's the
parsimony principle what you want to highlight here, and the first part
of the sentence is sufficient for capturing that without going into
concrete examples.

Section 3.3

This API is intended to support the various interactions expected
between most ASAs, such as the interactions outlined in Section 2.
However, if ASAs require additional communication between themselves,
they can do so using any desired protocol, even just a TLS session if
that meets their needs.  One option is to use GRASP discovery and

What is the meaning of "just" in "just a TLS session"?  Also it's not
clear what kind of messages would flow through this additional channel
and if there are any requirements in terms of their security properties.

[...] As
noted above, the ACP can secure such communications, unless there is
a good reason to do otherwise.

Maybe s/can/should/ and drop "unless ... otherwise"?

Section 6.1.1.

The typography used here to define inputs is a bit odd.  And in general
the whole section probably needs some more attention from an editorial
point of view.

Section 6.2

the agent piece of code (when this does not start automatically) and

Maybe drop "piece of".

Section 6.2.1

The operator's goal can be summarized in an instruction to the ANIMA
ecosystem matching the following format:

   [instances of ASAs of a given type] ready to control
   [Instantiation_target_Infrastructure] with
   [Instantiation_target_parameters]

Maybe better to move this at the beginning of Section 6.2.2.

Section 6.2.3

As in Section 6.1.1., the typographic style used here is a bit odd /

Re: [Gen-art] Gen-ART Telechat review of draft-ietf-anima-grasp-api-08

[Brian E Carpenter]

Paul,

We had a bit of delay on updating the ASA Guidelines draft, but the new version 
tries to cover your point at:

https://www.ietf.org/archive/id/draft-ietf-anima-asa-guidelines-01.html#section-5-2

Regards
   Brian Carpenter

On 05-Dec-20 07:21, Paul Kyzivat wrote:
> Brian,
> 
> Thanks. I'm happy now.
> 
>   Paul
> 
> On 12/3/20 4:22 PM, Brian E Carpenter wrote:
>> Below...
>>
>> On 04-Dec-20 04:17, Paul Kyzivat wrote:
>>> Brian,
>>>
>>> One more thing occurred to me:
>>>
>>> On 12/2/20 12:29 PM, Paul Kyzivat wrote:
>>>
>>>>>> Also, the goal of negotiation isn't clear to me. I gather it must be for
>>>>>> the two sides to agree on a particular value for the objective. But for
>>>>>> that to work there must be some rules about how values can change in
>>>>>> each step so that the result stabililizes, rather than causing a battle
>>>>>> that ends with loop count exhaustion. This could be achieved by always
>>>>>> negotiating *down*, or always *up*. But that requires that the objective
>>>>>> value type have an ordering function. Given the general nature of the
>>>>>> objective I don't think that can be assumed.
>>>>>
>>>>> No, it explicitly is not defined either in the protocol nor the API.
>>>>> The syntax and semantics of the objective value are defined
>>>>> per-objective,
>>>>> and the objective might or might not be ordered. So there is
>>>>> intentionally
>>>>> no answer to your question.
>>>>>
>>>>> In most cases I'd expect that there would be an ordering but we didn't
>>>>> want
>>>>> to constrain the use cases in that way. Also note that a failed
>>>>> negotiation
>>>>> (e.g. the loop count expires, or where one end simply rejects the other's
>>>>> offer) is not a protocol failure.
>>>>>
>>>>>>
>>>>>> ISTM that more work is needed to define the negotiation process in a way
>>>>>> that ensures it ends with both sides agreeing on a single value for the
>>>>>> objective.
>>>>>
>>>>> As noted, that is per-objective. The most complicated case I've coded
>>>>> is IP prefix assignment, and it works fine, except that if there is
>>>>> no prefix available of the maximum desired length, the requester ends
>>>>> up unsatisfied - as intended. There should be no condition in which
>>>>> the negotiation loops indefinitely; it either succeeds or fails.
>>>>
>>>> Without that the result in non-deterministic. The two sides may have
>>>> conflicting goals, and then the result will only be determined by the
>>>> loop count and timeout.
>>>>
>>>> Alternately, implementors will establish side agreements that aren't
>>>> governed by standards.
>>>>
>>>> That seems like an undesirable state of affairs.
>>>
>>> One possibility would be to define the negotiation policy on a
>>> per-objective basis. This would be required as part of the definition of
>>> the objective that is registered with IANA. It would define how the
>>> value may change from step to step of negotiation to ensure convergence.
>>
>> The IANA policy is Specification Required. We already have this in the
>> GRASP spec itself:
>>
>> There must be a well-defined procedure for concluding that a
>> negotiation cannot succeed, and if so deciding what happens next
>> (e.g., deadlock resolution, tie-breaking, or revert to best-effort
>> service).  This MUST be specified for individual negotiation
>> objectives.
>>
>> The natural place to expand on that is in draft-ietf-anima-asa-guidelines
>> as it develops.
>>
>> Regards
>>  Brian
>>
> 
> 

___
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-tls-external-psk-importer-05

[Brian E Carpenter]

FYI, the -06 draft satisfies all my concerns.

Thanks
   Brian Carpenter

On 07-Oct-20 15:24, Brian Carpenter via Datatracker wrote:
> Reviewer: Brian Carpenter
> Review result: Ready with Issues
> 
> Gen-ART Last Call review of draft-ietf-tls-external-psk-importer-05
> 
> 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-tls-external-psk-importer-05
> Reviewer: Brian Carpenter
> Review Date: 2020-10-07
> IETF LC End Date: 2020-10-15
> IESG Telechat date:  
> 
> Summary: Ready with issues
> 
> 
> Issues:
> ---
> 
>> 1.  Introduction
>>
>>Applications SHOULD provision separate PSKs for TLS 1.3 and prior
>>versions when possible.
> 
> I think that "when possible" could easily be used as a loophole by a
> lazy implementer. ("Impossible, because I'd have to refactor my code.")
> Since presumably this rule is to avoid all risk of a "related output"
> cryptanalytic vulnerability, why weaken the RFC2119 definition of SHOULD?
> The formal definition of SHOULD is stronger, with "the full implications
> must be understood and carefully weighed before choosing a different
> course." So I suggest simply deleting "when possible".
> 
>> 6.  Incremental Deployment
>>
>>   Recall that TLS 1.2 permits computing the TLS PRF with any hash
>>   algorithm and PSK.  Thus, an EPSK may be used with the same KDF (and
>>   underlying HMAC hash algorithm) as TLS 1.3 with importers.  However,
>>   critically, the derived PSK will not be the same since the importer
>>   differentiates the PSK via the identity and target KDF and protocol.
>>   Thus, PSKs imported for TLS 1.3 are distinct from those used in TLS
>>   1.2, and thereby avoid cross-protocol collisions.  Note that this
>>   does not preclude endpoints from using non-imported PSKs for TLS 1.2.
>>   Indeed, this is necessary for incremental deployment.
> 
> I read this three times and I have to ask whether "TLS 1.2" is
> really what you want in the penultimate line.
> 
> Nits:
> -
> 
>> 4.1.  External PSK Diversification
> ...
>>   ImportedIdentity.target_protocol MUST be the (D)TLS protocol version
>>   for which the PSK is being imported.  For example, TLS 1.3 [RFC8446]
>>   and QUICv1 [QUIC] use 0x0304. 
> 
> As far as I can tell, [QUIC] doesn't specify this, but draft-ietf-quic-tls
> does specify that QUICv1 uses TLS1.3. So the phrasing is a bit misleading.
> Maybe:
> 
>   For example, TLS 1.3 [RFC8446] uses 0x0304, which will therefore also be
>   used by QUICv1 [QUIC-TLS]. 
> 
> Are all the RFC2119 terms capitalised when required? For example, there
> are lower case 'may' and 'must' in the last paragraph of section 4.1
> (External PSK Diversification). I couldn't determine whether they were
> intended to be normative.
> 
> 
> 
> 
> ___
> Gen-art mailing list
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art
> 

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

Re: [Gen-art] Gen-ART Telechat review of draft-ietf-anima-grasp-api-08

[Brian E Carpenter]

Below...

On 04-Dec-20 04:17, Paul Kyzivat wrote:
> Brian,
> 
> One more thing occurred to me:
> 
> On 12/2/20 12:29 PM, Paul Kyzivat wrote:
> 
 Also, the goal of negotiation isn't clear to me. I gather it must be for
 the two sides to agree on a particular value for the objective. But for
 that to work there must be some rules about how values can change in
 each step so that the result stabililizes, rather than causing a battle
 that ends with loop count exhaustion. This could be achieved by always
 negotiating *down*, or always *up*. But that requires that the objective
 value type have an ordering function. Given the general nature of the
 objective I don't think that can be assumed.
>>>
>>> No, it explicitly is not defined either in the protocol nor the API.
>>> The syntax and semantics of the objective value are defined 
>>> per-objective,
>>> and the objective might or might not be ordered. So there is 
>>> intentionally
>>> no answer to your question.
>>>
>>> In most cases I'd expect that there would be an ordering but we didn't 
>>> want
>>> to constrain the use cases in that way. Also note that a failed 
>>> negotiation
>>> (e.g. the loop count expires, or where one end simply rejects the other's
>>> offer) is not a protocol failure.
>>>

 ISTM that more work is needed to define the negotiation process in a way
 that ensures it ends with both sides agreeing on a single value for the
 objective.
>>>
>>> As noted, that is per-objective. The most complicated case I've coded
>>> is IP prefix assignment, and it works fine, except that if there is
>>> no prefix available of the maximum desired length, the requester ends
>>> up unsatisfied - as intended. There should be no condition in which
>>> the negotiation loops indefinitely; it either succeeds or fails.
>>
>> Without that the result in non-deterministic. The two sides may have 
>> conflicting goals, and then the result will only be determined by the 
>> loop count and timeout.
>>
>> Alternately, implementors will establish side agreements that aren't 
>> governed by standards.
>>
>> That seems like an undesirable state of affairs.
> 
> One possibility would be to define the negotiation policy on a 
> per-objective basis. This would be required as part of the definition of 
> the objective that is registered with IANA. It would define how the 
> value may change from step to step of negotiation to ensure convergence.

The IANA policy is Specification Required. We already have this in the
GRASP spec itself:

   There must be a well-defined procedure for concluding that a
   negotiation cannot succeed, and if so deciding what happens next
   (e.g., deadlock resolution, tie-breaking, or revert to best-effort
   service).  This MUST be specified for individual negotiation
   objectives.

The natural place to expand on that is in draft-ietf-anima-asa-guidelines
as it develops.

Regards
Brian

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

Re: [Gen-art] Gen-ART Telechat review of draft-ietf-anima-grasp-api-08

[Brian E Carpenter]

Hi Paul,

Comments in line. There's one definite good catch in your
review, and obviously more clarifications are needed.

On 01-Dec-20 15:06, Paul Kyzivat 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 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 <​ 
> http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
> 
> Document: draft-ietf-anima-grasp-api-08
> Reviewer: Paul Kyzivat
> Review Date: 2020-11-30
> IETF LC End Date: 2020-10-28
> IESG Telechat date: 2020-12-01
> 
> Summary:
> 
> This draft is on the right track but has open issues, described in the 
> review.
> 
> General:
> 
> This document has addressed some of the concerns I had during the last 
> call review. However some of my concerns remain and some new ones have 
> arisen in this version.
> 
> Issues:
> 
> Major: 3
> Minor: 6
> Nits:  1
> 
> 1) MAJOR: Negotiation
> 
> The text in section 2.3.5 now makes clear that the sequence of steps in 
> the negotiation is non-deterministic - both sides can call 
> negotiate_step and negotiate_wait. I believe this can result in the two 
> sides not agreeing on what values have been negotiated. (For instance, 
> what if one side calls negotiate_step concurrently with the other side 
> calling end_negotiate? Which value has been agreed upon?) 

The negotiate_step calls alternate between the two peers, until one of them
calls end_negotiate (or a timeout kills the session). I hoped that
was clear in the protocol diagram. We can make it explicit, for people
who haven't fully digested the protocol spec. Since that's ~50 pages, it
certainly takes some digestion.

(negotiate_wait would be interjected by the peer who has the next go, simply
indicating that the next step is delayed. That could happen, for example,
if the ASA needed to negotiate something with a third party before
continuing.)

> The loop_count 
> adds to the confusion. Are the two sides intended to have independent 
> loop count values? It seems these too can become unsynchronized.

The loop count also bounces backwards and forwards in alternate steps.
Again, we can underline that in the text.

> Also, the goal of negotiation isn't clear to me. I gather it must be for 
> the two sides to agree on a particular value for the objective. But for 
> that to work there must be some rules about how values can change in 
> each step so that the result stabililizes, rather than causing a battle 
> that ends with loop count exhaustion. This could be achieved by always 
> negotiating *down*, or always *up*. But that requires that the objective 
> value type have an ordering function. Given the general nature of the 
> objective I don't think that can be assumed.

No, it explicitly is not defined either in the protocol nor the API.
The syntax and semantics of the objective value are defined per-objective,
and the objective might or might not be ordered. So there is intentionally
no answer to your question.

In most cases I'd expect that there would be an ordering but we didn't want
to constrain the use cases in that way. Also note that a failed negotiation
(e.g. the loop count expires, or where one end simply rejects the other's
offer) is not a protocol failure.

> 
> ISTM that more work is needed to define the negotiation process in a way 
> that ensures it ends with both sides agreeing on a single value for the 
> objective.

As noted, that is per-objective. The most complicated case I've coded
is IP prefix assignment, and it works fine, except that if there is
no prefix available of the maximum desired length, the requester ends
up unsatisfied - as intended. There should be no condition in which
the negotiation loops indefinitely; it either succeeds or fails.

> 
> 2) MINOR: Dry Run Negotiation
> 
> Dry Run negotiation is very under-specified. Why would it be used? I 
> guess that an ASA might use dry run negotiation to inform future actual 
> negotiation. Can anything be inferred from a dry run negotiation about 
> how an actual negotiation will go? When participating in a dry run 
> negotiation, how should an ASA decide what response to make? Should it 
> take into account current resource availability? Or should it respond 
> based on best-case or worst-case resource availability? Or what?
> 
> This requires further clarification.

Again, *all* these issues are specific to the objective in question,
and they are intentionally not addressed in the protocol design or
the API.
 
> 3) MAJOR: Confusing semantics of 'request_negotiate'
> 
> In section 2.3.5 I don't understand the following:
> 
>   1.  The 'session_nonce' parameter is null.  In this case the
>   negotiation has succeeded in one step and the peer has
>   accepted the request.  The returned 'proffered_objective'
>  

Re: [Gen-art] Gen-ART Last Call review of draft-ietf-anima-grasp-api-07

[Brian E Carpenter]

Thanks Paul. We'll try to clarify those points in the text, so I
won't comment in detail on your comments. I can see how your questions
arise for a newcomer to GRASP, so they do need to be answered. It will
take a little while to do this, so the AD will defer the draft to a
later telechat.

Regards
   Brian Carpenter

On 29-Oct-20 04:50, Paul Kyzivat 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-grasp-api-07
> Reviewer: Paul Kyzivat
> Review Date: 2020-10-28
> IETF LC End Date: 2020-10-28
> IESG Telechat date: ?
> 
> This draft is on the right track but has open issues, described in the 
> review.
> 
> General:
> 
> I began this review without any knowledge of Anima. I did read several 
> of the related documents for context, but my overall understanding 
> remains somewhat sketchy. So take my comments with with that in mind. 
> (At least you get a fresh, untainted perspective.)
> 
> Issues:
> 
> Major: 5
> Minor: 6
> Nits:  2
> 
> 1) MAJOR: Unclear model for API function usage
> 
> As I read through sections 2.3.2 through 2.3.6 these I got progressively 
> more confused. I finally concluded that a big picture of how API 
> functions interact is lacking.
> 
> For one thing, there isn't a clear delineation between those calls used 
> by requesters and those used by responders. And then valid sequencing of 
> calls is hard to tease out.
> 
> It would be helpful to have one state model for requesters and another 
> for responders. It may also be helpful to break this out for threaded 
> and event loop variants.
> 
> My subsequent issues regarding these sections are reflective of this 
> confusion.
> 
> 2) MAJOR: What state does GRASP retain for Objectives?
> 
> It is clear that the GRASP must retain the names of registered 
> objectives. There are implications that it must keep more. Seemingly it 
> must retain received flooded objectives, on a per-source basis. It is 
> unclear if it is only for registered objectives, or also for 
> unregistered objectives. This could potentially become a large resource 
> drain if there are lots of nodes flooding values.
> 
> Negotiated objectives seem to be treated differently. It isn't clear to 
> me if GRASP needs to retain copies of their values.
> 
> 3) MAJOR: Consistency of Objective definitions
> 
> In section 2.3.1.2 and elsewhere, presumably all parties that use a 
> particular objective must agree on the values of synch, neg, dry, and 
> the format of the value.
> 
> Apparently you are relying on each caller getting this right. What 
> happens when this isn't the case? How can blame be ascribed so that the 
> problem can be fixed?
> 
> 4) MAJOR: Confusing semantics of 'request_negotiate'
> 
> In section 2.3.4 I don't understand the following:
> 
>   1.  The 'session_nonce' parameter is null.  In this case the
>   negotiation has succeeded immediately (the peer has
>   accepted the request).  The returned 'proffered_objective'
>   contains the value accepted by the peer.
> 
> IIUC this requires a network exchange with the peer. I don't see how 
> this can complete *immediately*. ISTM that this could only complete 
> immediately if it were satisfied from a local cache. That doesn't seem 
> appropriate for this function.
> 
> Similarly, in bullet 2 I don't see how the proffered_objective would be 
> available in the initial call.
> 
> Or is this text only applicable to a threaded implementation with 
> synchronous calls?
> 
> Bullet 2 also says:
> 
>   ... The
>   returned 'proffered_objective' contains the first value
>   proffered by the negotiation peer.  The contents of this
>   instance of the objective must be used in the subsequent
>   negotiation call because it contains the updated loop
>   count, sent by the negotiation peer.
> 
> Do you mean this must be used in the call to negotiate_step? But that 
> would mean asking for what has already been granted. For the the 
> negotiation to be useful I would expect that the next round would ask 
> for a value somewhere between what was originally requested and what was 
> initially offered.
> 
> I think you need to say more about the whole concept of negotiation and 
> how it is expected to work. Also, additional discussion of the purpose 
> and semantics of dry run negotiation.
> 
> One more thing: you don't explain the semantics of 'timeout'. Is it only 
> used locally, to terminate the synchronous form of the call? Or is it 
> transmitted and used by the responder to control how long it might spend 
> trying to fulfill the request before giving up?
> 
> 5) MAJOR: 

Re: [Gen-art] [Last-Call] [dispatch] Genart last call review of draft-hardie-dispatch-rfc3405-update-03

[Brian E Carpenter]

On 03-Sep-20 05:41, Ted Hardie wrote:
> To reply to the text change in particular:
> 
> On Wed, Sep 2, 2020 at 3:52 AM Timothy Mcsweeney  > wrote:
> 
> __
> 
> >>This draft could spell out each of those edits precisely, or just 
> replace all of Section 3.1.1 with a new set of text..
>  
> And it should.  There is no legitimate reason not to.  
>  
>   
> 
> 
> You would prefer changing this:
> 
> 2.  Updated Requirements
> 
>This document removes the normative requirement from RFC 3405 for
>registrations in URI.ARPA to be from the IETF URI Tree.
> 
>All registrations in URI.ARPA MUST now be for schemes which are
>permanent registrations, as they are described in BCP 35.
> 
> to something like this:
> 
> 2. Updated section 3.1.1 for RFC 3405
> 
> The following text replaces section 3.1.1 of RFC 3405:
> 
>3.1.1 Only permanent URI registrations allowed.
> 
>All schemes registered in URI.ARPA MUST be schemes which are
>permanent registrations, as they are described in BCP 35.
> 
> Is that right?

Re-assuming my hat as a Gen-ART reviewer for this draft, I think that this
change would be a mistake, as it no longer explicitly  informs the reader
what has been changed in RFC 3405.

If we really want to be precise, I suggest:

2.  Updated Requirements
 
   This document removes the normative requirement from section 3.1.1
   of RFC 3405 for registrations in URI.ARPA to be from the IETF URI Tree.

   All registrations in URI.ARPA MUST now be for schemes which are
   permanent registrations, as they are described in BCP 35.

Regards
   Brian

> 
> regards,
> 
> Ted Hardie
> 
> >>... seems equivalent and unambiguous to me.
>  
> No surprise here.  Maybe the IESG isn't a good fit for you.  As a matter 
> of fact, if I were Barry I would drop sponsorship of this draft for all the 
> reasons above. 
>  
>  
>  
>  
>  
>  
>  
>  
>> On 09/02/2020 1:49 AM Murray S. Kucherawy > > wrote:
>>  
>>  
>> On Tue, Sep 1, 2020 at 8:58 AM Timothy Mcsweeney > > wrote:
>>
>> >While it's certainly possible to add such guidance now, this update 
>> is 
>>
>> >very narrowly targeted to fix a serious problem, and I would not 
>> want
>> >debate about additional text to get in the way of that.
>>  
>> And doesn't using this draft as an update of the entire IANA 
>> considerations section effectively remove any means of registration through 
>> the mailing lists provided in that same section??  
>>
>>  
>> This draft doesn't replace the entire IANA Considerations section of RFC 
>> 3405, but rather amends it.  That is, after this is published, to get the 
>> full IANA Considerations for BCP 65, you would read RFC 3405 and then apply 
>> this document as a sort of "patch".  That's what we mean when we say "RFC Y 
>> updates RFC X", which will be the end result here.
>>  
>> The specific effect of this document when published is to amend Section 
>> 3.1.1 of RFC 3405 such that instead of saying "registered under the IETF URI 
>> tree", it becomes "a registered permanent URI scheme", and then take "tree" 
>> out of the next sentence, and rename the section to something more 
>> appropriate.  This draft could spell out each of those edits precisely, or 
>> just replace all of Section 3.1.1 with a new set of text, but it's such a 
>> small change that what's here seems equivalent and unambiguous to me.
>>  
>> -MSK
>> -- last-call mailing list last-c...@ietf.org  
>> https://www.ietf.org/mailman/listinfo/last-call 
> 

___
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-mmusic-msrp-usage-data-channel-21

[Brian E Carpenter]

Thanks Christer, that all looks good to me,

Regards
   Brian

On 13-Jul-20 20:58, Christer Holmberg wrote:
> Hi Brian,
> 
> Thank You for the review! Please see inline.
> 
> 
> Nits:
> -
> 
>>> 4.1.  MSRP URI
>>> 
>>> transport  /= "dc"
>>>
>>> I see that RFC7977 takes a slightly different approach to updating the ABNF:
>>>
>>> transport  =  "tcp" / "ws" / 1*ALPHANUM
>>>
>> The advantage of listing out
>>
>>  transport  =  "tcp" / "ws" / "dc" / 1*ALPHANUM
>>
>> would be that the reader sees the full list.
> 
> The MMUSIC WG has previously decided to take the approach of only writing the 
> new value, using the "/=" format.
> 
> ---
> 
>>>  ; Add "dc" to existing transports per [RFC4975]
>>>
>>> I suggest
>>>
>>> ; Add "dc" to existing transports per Section 9 of [RFC4975]
> 
> Will modify as suggested.
> 
> ---
> 
>>> 4.6.  Session Closing
>>>
>>>   The SDP answerer must ensure that no dcmap or dcsa attributes are
>>>   present in the SDP answer if no corresponding attributes are present
>>>   in the received SDP offer.
>>>
>>> Should that be MUST?
> 
> The reason for "must" is that is referring to generic data channel SDP O/A 
> procedures.
> 
> I suggest to remove the paragraph.
> 
> ---
> 
>>> B2BUA
>>>
>>> Define the acronym please.
> 
> We normally don't do that in MMUSIC specifications. Also, it is on the IETF 
> list of well-known acronyms.
> 
> Having said that, I am fine to enhance it on first occurrence: 'Back-to-Back 
> User Agent (B2BUA)'
> 
> ---
> 
>>> 9.2.  Subprotocol Identifier MSRP
>>>
>>>   A reference to this document is added to the subprotocol identifier
>>>   "msrp" in the "WebSocket Subprotocol Name Registry"
>>>
>>> s/this document/RFC/
> 
> Will modify as suggested.
> 
> ---
> 
>>> 11.  CHANGE LOG
>>>
>>> Mark this section for deletion by the RFC Editor
> 
> I think the RFC Editor will delete it by default, but we can add explicit 
> text.
> 
> Regards,
> 
> Christer
> 

___
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-mmusic-msrp-usage-data-channel-21

[Brian E Carpenter]

On 14-Jul-20 02:58, Paul Kyzivat wrote:
> Brian,
> 
> On 7/12/20 6:40 PM, Brian Carpenter via Datatracker wrote:
> 
>> Nits:
>> -
>>
 4.1.  MSRP URI
>> 
  transport  /= "dc"
>>
>> I see that RFC7977 takes a slightly different approach to updating the ABNF:
>>
  transport  =  "tcp" / "ws" / 1*ALPHANUM
>>
>> The advantage of listing out
>>
>>transport  =  "tcp" / "ws" / "dc" / 1*ALPHANUM
>>
>> would be that the reader sees the full list.
> 
> While it might be nice to see the full list, it can't be counted on to 
> remain the full list. If each update did this, then every draft that 
> updates the list should formally Update every other document that 
> updates the list.
> 
> The *point* of /= in abnf is that it decouples the particular addition 
> from all others.

Sure, I realise that. But...
 
> This sort of thing should really have an IANA registry. But often the 
> expectation is that changes aren't made often enough to justify that. 

Indeed, that occurred to me as an alternative approach but a registry
with 3 entries is a bit light (and also, readers starting at RFC4975
wouldn't know to look for the registry).

> Lacking that, IMO /= is the preferred way to go.

It was only a nit...

Brian

> 
>   Just kibitzing,
>   Paul
> 
> 
> 

___
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-git-using-github-04

[Brian E Carpenter]

Thanks
   Brian

On 04-Mar-20 15:06, Alissa Cooper wrote:
> I put this in an RFC Editor note.
> Alissa
> 
>> On Feb 24, 2020, at 11:04 AM, Martin Thomson  wrote:
>>
>> Thanks Brian,
>>
>> On Sun, Feb 23, 2020, at 17:01, Brian Carpenter via Datatracker wrote:
>>> Is this draft intended to become part of BCP25? I think it would be
>>> useful for the IESG to clarify this rather than leave it to the RFC Editor.
>>
>> This is a good question.  Given the intended status of BCP, I would say that 
>> integrating into 25 is better than creating a new number.  I don't know how 
>> to best signal this intent though.
>>
>> And I fixed the nit in the copy on GitHub.
>>
>> ___
>> Gen-art mailing list
>> Gen-art@ietf.org
>> https://www.ietf.org/mailman/listinfo/gen-art
> 
> 

___
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-bess-nsh-bgp-control-plane-12

[Brian E Carpenter]

Hi,

For the record, the -13 version addresses all my comments.

Thanks
   Brian Carpenter

On 11-Dec-19 11:49, Brian E Carpenter wrote:
> Thanks Adrian. All OK for me, with one inserted comment below.
> 
> Regards
>Brian
> 
> On 10-Dec-19 23:07, Adrian Farrel wrote:
>> Hi Brian,
>>
>> Thanks for your time with this.
>>
>> In line...
>>
>>> Comments:
>>> -
>>>
>>> I am not a BGP expert and did not check the BGP details. This
>>> is a pretty complex mechanism so I would have liked to hear of
>>> at least a lab-scale implementation. I wouldn't be shocked if
>>> this was diverted to Experimental.
>>
>> At the moment I don't have access to a lab, so I won't comment about that.
>> I will note four things:
>> 1. I don't consider the mechanism to be "pretty complex", but "rather 
>> simple". It may be that the difference is whether you have to pick up all of 
>> BGP to understand this draft or whether it comes as a small increment.
>> 2. Obviously (?) the document has had eyes from a number of BGP experts 
>> especially a very careful review by the document shepherd. It was shared 
>> with IDR and caught comments from one of the IDR chairs.
>> 3. It's an IBGP mechanism not an EBGP mechanism, so the exposure to the 
>> stability of the Internet is reduced.
>> 4. The BESS chairs ran a poll on the list to determine whether to progress 
>> as is in advance of implementations.
>>
>>> Minor issues:
>>> -
>>> Actually these are mainly questions:
>>
>> Questions are good.
>>
>>> There are numerous references, starting in the Abstract, to the
>>> "Controller" but it isn't defined or described in any one place.
>>> I expected to find it in RFC8300, but no. So what is the Controller?
>>
>> Right. This is a good catch. A "controller" is a centralised component 
>> responsible for determining SFPs and maybe more. It is akin to an SDN 
>> controller. We definitely need to add text for this.
>>
>> It is not an 8300 concept. Indeed, 8300 is principally focused on the 
>> forwarding plane.
>> Furthermore, the control plane and orchestration aspects of SFC are a bit 
>> sketchy in 7665.
>> draft-ietf-sfc-control-plane might have been a good source of information, 
>> but the SFC WG appears to have given up on it.
>>
>> So, yes, we need a short definition in 1.2, and a paragraph in 2.2.
>>
>>> RFC8300 requires NSH+original_packet to be encapsulated in a Transport
>>> Encapsulation. In section 2.1 we find:
>>>
>>>>  Note that the presence of the NSH can make it difficult for nodes in
>>>>  the underlay network to locate the fields in the original packet that
>>>>  would normally be used to constrain equal cost multipath (ECMP)
>>>>  forwarding.  Therefore, it is recommended that the node prepending
>>>>  the NSH also provide some form of entropy indicator that can be used
>>>>  in the underlay network.  How this indicator is generated and
>>>>  supplied, and how an SFF generates a new entropy indicator when it
>>>>  forwards a packet to the next SFF are out of scope of this document.
>>>
>>> I would have expected that text to state that the entropy indicator is
>>> a property of the Transport Encapsulation required by RFC8300. (Isn't
>>> the Service Function Overlay Network in fact the embodiment of the
>>> Transport Encapsulation?) 
>>
>> Well, yes and no.
>> The entropy indicator is carried in the transport encapsulation, and is used 
>> by the transport (underlay) network.
>> But it is a property of the payload. In particular, it is a property of what 
>> is encapsulated by the NSH.
>> The mechanism that encapsulates for the transport would normally have 
>> visibility into the payload to create the entropy indicator (hashing on 
>> specific fields), but the inclusion of the NSH makes that harder. Hence the 
>> recommendation that the entropy indicator is provided by the mechanism that 
>> prepends the NSH.
> 
> Yes, understood. Of course IPv6 has its own header field precisely for this 
> purpose and both RFC6437 and RFC6438 are there to help you ;-). Shame about 
> IPv4.
> 
>>
>> I think the text says this and that those skilled in the art (you have to 
>> understand the use of the entropy indicators and the inclusion of the NSH) 
>> will get this.
>>
>>> In section 2.2 we find:
>>>
>>>>  When choosing the n

Re: [Gen-art] Genart last call review of draft-ietf-bess-nsh-bgp-control-plane-12

[Brian E Carpenter]

Thanks Adrian. All OK for me, with one inserted comment below.

Regards
   Brian

On 10-Dec-19 23:07, Adrian Farrel wrote:
> Hi Brian,
> 
> Thanks for your time with this.
> 
> In line...
> 
>> Comments:
>> -
>>
>> I am not a BGP expert and did not check the BGP details. This
>> is a pretty complex mechanism so I would have liked to hear of
>> at least a lab-scale implementation. I wouldn't be shocked if
>> this was diverted to Experimental.
> 
> At the moment I don't have access to a lab, so I won't comment about that.
> I will note four things:
> 1. I don't consider the mechanism to be "pretty complex", but "rather 
> simple". It may be that the difference is whether you have to pick up all of 
> BGP to understand this draft or whether it comes as a small increment.
> 2. Obviously (?) the document has had eyes from a number of BGP experts 
> especially a very careful review by the document shepherd. It was shared with 
> IDR and caught comments from one of the IDR chairs.
> 3. It's an IBGP mechanism not an EBGP mechanism, so the exposure to the 
> stability of the Internet is reduced.
> 4. The BESS chairs ran a poll on the list to determine whether to progress as 
> is in advance of implementations.
> 
>> Minor issues:
>> -
>> Actually these are mainly questions:
> 
> Questions are good.
> 
>> There are numerous references, starting in the Abstract, to the
>> "Controller" but it isn't defined or described in any one place.
>> I expected to find it in RFC8300, but no. So what is the Controller?
> 
> Right. This is a good catch. A "controller" is a centralised component 
> responsible for determining SFPs and maybe more. It is akin to an SDN 
> controller. We definitely need to add text for this.
> 
> It is not an 8300 concept. Indeed, 8300 is principally focused on the 
> forwarding plane.
> Furthermore, the control plane and orchestration aspects of SFC are a bit 
> sketchy in 7665.
> draft-ietf-sfc-control-plane might have been a good source of information, 
> but the SFC WG appears to have given up on it.
> 
> So, yes, we need a short definition in 1.2, and a paragraph in 2.2.
> 
>> RFC8300 requires NSH+original_packet to be encapsulated in a Transport
>> Encapsulation. In section 2.1 we find:
>>
>>>  Note that the presence of the NSH can make it difficult for nodes in
>>>  the underlay network to locate the fields in the original packet that
>>>  would normally be used to constrain equal cost multipath (ECMP)
>>>  forwarding.  Therefore, it is recommended that the node prepending
>>>  the NSH also provide some form of entropy indicator that can be used
>>>  in the underlay network.  How this indicator is generated and
>>>  supplied, and how an SFF generates a new entropy indicator when it
>>>  forwards a packet to the next SFF are out of scope of this document.
>>
>> I would have expected that text to state that the entropy indicator is
>> a property of the Transport Encapsulation required by RFC8300. (Isn't
>> the Service Function Overlay Network in fact the embodiment of the
>> Transport Encapsulation?) 
> 
> Well, yes and no.
> The entropy indicator is carried in the transport encapsulation, and is used 
> by the transport (underlay) network.
> But it is a property of the payload. In particular, it is a property of what 
> is encapsulated by the NSH.
> The mechanism that encapsulates for the transport would normally have 
> visibility into the payload to create the entropy indicator (hashing on 
> specific fields), but the inclusion of the NSH makes that harder. Hence the 
> recommendation that the entropy indicator is provided by the mechanism that 
> prepends the NSH.

Yes, understood. Of course IPv6 has its own header field precisely for this 
purpose and both RFC6437 and RFC6438 are there to help you ;-). Shame about 
IPv4.

> 
> I think the text says this and that those skilled in the art (you have to 
> understand the use of the entropy indicators and the inclusion of the NSH) 
> will get this.
> 
>> In section 2.2 we find:
>>
>>>  When choosing the next SFI in a path, the SFF uses the SPI and SI as
>>>  well as the SFT to choose among the SFIs, applying, for example, a
>>>  load balancing algorithm or direct knowledge of the underlay network
>>>  topology as described in Section 4.
>>
>> I'm probably missing something, but doesn't that risk a conflict with
>> the statement above about the entropy indicator? How would this choice
>> of path be guaranteed congruent with the choice of path by the underlay
>> network? Or doesn't that matter?
> 
> No, this is a choice of SFIs, not a choice of paths between SFFs.
> The former is determining the path in the overlay, the latter (using the 
> entropy indicator) is selecting the path through the underlay.
> 
>>> 4.4.  Classifier Operation
>>>
>>>  As shown in Figure 1, the Classifier is a component that is used to
>>>  assign packets to an SFP.
>>>
>>>  The Classifier is responsible for determining to which packet flow a
>>>  

Re: [Gen-art] [DNSOP] I-D Action: draft-ietf-dnsop-serve-stale-09.txt

[Brian E Carpenter]

Ben,

It's certainly a judgment call, but it really does seem that uint_32t has been 
around so long now that surviving implementations that misuse int for this 
surely have many other problems too. We'd be talking about resolver code that 
hasn't been refurbished since 1997 *and* a DNS record with an absurdly large 
TTL.

I think DNSOP participants are better placed than me to comment.

Regards
   Brian Carpenter

On 03-Dec-19 08:33, Benjamin Kaduk wrote:
> Hi Brian,
> 
> I agree that this updated text provides more clarity about why the
> change is being made, but I am not sure that it fully addresses all of
> the concerns you raised, and would appreciate your thoughts.
> 
> Specifically, you had raised the possibility of existing, fielded,
> implementations that would behave poorly when presented with input that
> has the sign bit set.  The DNS-OARC data that indicates such packets have
> not been seen in the wild serves only to amplify this uncertainty, since
> we have no reason to believe that such a codepath would have been triggered
> already and diagnosed.  Isn't there still some latent risk of such
> fielded implementations that would be incompatible with this change if it
> ever did show up on the wire?
> 
> Thanks,
> 
> Ben
> 
> On Fri, Oct 25, 2019 at 11:23:42AM +1300, Brian E Carpenter wrote:
>> Hi Dave,
>>
>> Thanks. I think that covers it. I still suspect that the original reason
>> was concern about int versus uint confusion, but the new text is fine.
>>
>> Regards
>>Brian Carpenter
>>
>> On 25-Oct-19 08:35, Dave Lawrence wrote:
>>> internet-dra...@ietf.org writes:
>>>> A diff from the previous version is available at:
>>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-serve-stale-09
>>>
>>> This revision addressed the one remaining outstanding issue that Brian
>>> Carpenter raised in the Gen-ART Last Call Review.  The following text
>>> was added to explain why a TTL with the high-order bit set is now
>>> handles as a large positive number (then capped down) rather than a
>>> negative number (and treated as zero).
>>>
>>> As for the change to treat a TTL with the high-order bit set as
>>> positive and then clamping it, as opposed to [RFC2181] treating it as
>>> zero, the rationale here is basically one of engineering simplicity
>>> versus an inconsequential operational history.  Negative TTLs had no
>>> rational intentional meaning that wouldn't have been satisfied by just
>>> sending 0 instead, and similarly there was realistically no practical
>>> purpose for sending TTLs of 2^25 seconds (1 year) or more.  There's
>>> also no record of TTLs in the wild having the most significant bit set
>>> in DNS-OARC's "Day in the Life" samples.  With no apparent reason for
>>> operators to use them intentionally, that leaves either errors or
>>> non-standard experiments as explanations as to why such TTLs might be
>>> encountered, with neither providing an obviously compelling reason as
>>> to why having the leading bit set should be treated differently from
>>> having any of the next eleven bits set and then capped per Section 4.
>>>
>>> I also removed the phrasing about 2181's handling of this issue as a
>>> "curious suggestion".  I recognize it could have an unintended
>>> negative connotation against the original authors, though when I wrote
>>> the sentence originally I meant it only with its neutral denotation.
>>> It was curious to me only because no rationale was provided as to why
>>> that particular choice had been made, despite the current assertion
>>> that it was obvious as to why.
>>>
>>>
>>
> 

___
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-regext-login-security-05

[Brian E Carpenter]

James,

Comments in line:
On 06-Nov-19 07:58, Gould, James wrote:
> Brian,  
> 
> Thank you for your review and feedback.  My responses are embedded below.  I 
> will include updates based on your feedback in 
> draft-ietf-regext-login-security-06 at the conclusion of the last call.
> 
> --  
> 
> JG
> 
> James Gould
> Distinguished Engineer
> jgo...@verisign.com 
> 

> 703-948-3271
> 12061 Bluemont Way
> Reston, VA 20190 
> Verisign.com  
> 
> On 11/2/19, 11:49 PM, "Brian Carpenter via Datatracker"  
> wrote:
> 
>     Reviewer: Brian Carpenter
>     Review result: Ready with Issues
> 
> Gen-ART Last Call review of draft-ietf-regext-login-security-05
> 
> 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-regext-login-security-05.txt
>     Reviewer: Brian Carpenter
>     Review Date: 2019-11-03
>     IETF LC End Date: 2019-11-12
>     IESG Telechat date: 
> 
> Summary: Ready with minor issues
>     
> 
> Minor issues:
>     -
> 
> I found section 2 "Migrating to Newer Versions of This Extension"
>     a little hard to follow. Firstly, am I correct in assuming that
>     "a new version" means a version number higher than 1.0, e.g.
>     "loginSec-1.1"? That is probably the intended meaning, but I think
>     it needs to be explicit. Maybe state that this document defines
>     "loginSec-1.0" and future documents can define other minor and major
>     versions such as "loginSec-1.1" or "loginSec-2.0".
> 
> JG - The "Migration to Newer Versions of This Extension" section was 
> originally meant to address point version updates (e.g., loginSec-0.2, 
> loginSec-0.3) prior to version loginSec-1.0, but Barry Leiba's review 
> feedback recommended leaving it in the draft.  This section is applicable to 
> any version change, including migrating from a pre-loginSec-1.0 version to 
> loginSec-1.0 or a future update of loginSec-1.0 to loginSec-1.1.  I believe 
> the language needs to remain generic to apply to both cases. 

Yes, that makes sense. I think that because this section occurs *before* the 
technical details it isn't quite clear what "version" means - I certainly had 
to come back to this section after reading the whole text. But you probably 
don't want to mention loginSec-0.x, hence the examples I suggested. 

> Then "(for a temporary migration period)" is a bit vague. I think
>     it would be useful to suggest the order of magnitude of the overlap
>     period: days?, months?; hopefully not years.
>  
> JG - The migration period is up to server policy.  It could be made more 
> explicit by changing it to read "(for a temporary migration period *up to 
> server policy*)".  Do you agree with this change?

Making it clear that it's a policy choice is an improvement, yes. But I still 
think that it would be useful to indicate a timescale. I've seen migration 
overlaps ranging anywhere from seconds to years in different protocols and I 
really have no idea where this one lies on that spectrum.

> I also think a short discussion of adding & removing versions is version
>     needed in the Security Considerations, since the reason for a new
>     version might be the discovery of a vulnerability in the current
>     version. That's when a short migration period is desirable.
> 
> JG – I don’t see the linkage of adding & removing versions to the Security 
> Considerations, since a version change may be due to multiple reasons 
> (functional issue, functional enhancement, and security).  The length of time 
> for the migration is up to server policy based on many factors outside of the 
> protocol. 

Of course. But the specific case of a security-driven update is special and may 
be much more urgent than normal policy. That's why I'd be inclined to mention 
it. Not a big deal, however.

Regards
   Brian Carpenter
   
> FYI, there are some other extension design considerations in
>     https://tools.ietf.org/html/rfc6709#section-4 . 
> 
> JG – Thank you, I’ll be sure to review 
> https://tools.ietf.org/html/rfc6709#section-4.
> 
> Nits:
>     -
> 
> "1.  Introduction
> 
>    This document describes an Extensible Provisioning Protocol (EPP)
>    extension for enhancing the security of the EPP login command in EPP
>    RFC 5730.  The enhancements include supporting longer passwords (or
>    passphrases) than the 16-character maximum and providing a list of
>    security events in the login response.  The password (current and
>    new) in EPP RFC 5730 can be overridden..."
> 
> "RFC 5730" should either be in parenthesis as "(RFC 5730)" or
>     a reference 

Re: [Gen-art] [DNSOP] I-D Action: draft-ietf-dnsop-serve-stale-09.txt

[Brian E Carpenter]

Hi Dave,

Thanks. I think that covers it. I still suspect that the original reason
was concern about int versus uint confusion, but the new text is fine.

Regards
   Brian Carpenter

On 25-Oct-19 08:35, Dave Lawrence wrote:
> internet-dra...@ietf.org writes:
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-serve-stale-09
> 
> This revision addressed the one remaining outstanding issue that Brian
> Carpenter raised in the Gen-ART Last Call Review.  The following text
> was added to explain why a TTL with the high-order bit set is now
> handles as a large positive number (then capped down) rather than a
> negative number (and treated as zero).
> 
> As for the change to treat a TTL with the high-order bit set as
> positive and then clamping it, as opposed to [RFC2181] treating it as
> zero, the rationale here is basically one of engineering simplicity
> versus an inconsequential operational history.  Negative TTLs had no
> rational intentional meaning that wouldn't have been satisfied by just
> sending 0 instead, and similarly there was realistically no practical
> purpose for sending TTLs of 2^25 seconds (1 year) or more.  There's
> also no record of TTLs in the wild having the most significant bit set
> in DNS-OARC's "Day in the Life" samples.  With no apparent reason for
> operators to use them intentionally, that leaves either errors or
> non-standard experiments as explanations as to why such TTLs might be
> encountered, with neither providing an obviously compelling reason as
> to why having the leading bit set should be treated differently from
> having any of the next eleven bits set and then capped per Section 4.
> 
> I also removed the phrasing about 2181's handling of this issue as a
> "curious suggestion".  I recognize it could have an unintended
> negative connotation against the original authors, though when I wrote
> the sentence originally I meant it only with its neutral denotation.
> It was curious to me only because no rationale was provided as to why
> that particular choice had been made, despite the current assertion
> that it was obvious as to why.
> 
> 

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

[Gen-art] Process issue: no Last Call for draft-ietf-netmod-yang-data-ext

[Brian E Carpenter]

Hi,

I've been assigned as Gen-ART reviewer for draft-ietf-netmod-yang-data-ext, 
which is on the IESG agenda for 2019-10-31, but there has been no IETF Last 
Call.

I'll do the review, but you'll need to do the Last Call and defer the draft, I 
fear.

Regards
   Brian Carpenter

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

Re: [Gen-art] [ipwave] Genart last call review of draft-ietf-ipwave-ipv6-over-80211ocb-46

[Brian E Carpenter]

Because of the non-plain text and the commenting styles used, I am
unclear who wrote what below, but please see my comment in line:
On 23-Jun-19 18:18, Roni Even (A) wrote:
> 
> Inline
> 
> 
> From: Roni Even (A) [mailto:roni.e...@huawei.com]
> Sent: Tuesday, June 18, 2019 1:41 AM
> To: dick...@alum.mit.edu; 'NABIL BENAMAR'; 'Roni 
> Even'
> Cc: gen-art@ietf.org; 'IETF Discussion'; 
> i...@ietf.org; 
> draft-ietf-ipwave-ipv6-over-80211ocb@ietf.org
> Subject: RE: [ipwave] [Gen-art] Genart last call review of 
> draft-ietf-ipwave-ipv6-over-80211ocb-46
> 
> Hi,
> I am not a security expert, I was just trying to reflect that when reading 
> the document I got the impression that privacy is a major concern since the 
> IP-OBU is moving and its location can be traced by sniffing the MAC addresses.
> [RR] FYI ... there is no such thing as an IP-OBU unless this group chooses to 
> define one.  I highly recommend against it for a variety of reasons including 
> adding a network protocol identifier in front of a device identifier makes no 
> sense.
> 
> [RE] IP-OBU is defined in section 2 and is used in 5.1 when discussing privacy
> 
> 
> Maybe it will be good to have a security review of the document. I also 
> noticed that there is support in IEEE SA - 1609.4-2016 for MAC address change.
> 
> [RR] Yes, but it does NOT make such changes mandatory!   I made sure of that 
> for the same reasons stated below.

The draft says, in section 5:

   For this reason, in the 802.11-OCB
   deployments, there is a strong necessity to use protection tools such
   as dynamically changing MAC addresses Section 5.2, semantically
   opaque Interface Identifiers and stable Interface Identifiers
   Section 4.4.  This may help mitigate privacy risks to a certain
   level.

I'm not quite sure how "strong necessity" relates to RFC2119 terminology,
but the current text seems to say that changing MAC addresses is at
least RECOMMENDED.

Also the quoted text is very hard to parse. Does "semantically opaque"
qualify "Interface Identifiers" or "Interface Identifiers and stable
"Interface Identifiers"? And how do stable Interface Identifiers help
to protect privacy?

(FYI, the data tracker does show that a SECDIR review has been requested.)

Regards
Brian Carpenter

> 
> 
> 
> Roni Even
> 
> From: Dick Roy [mailto:dick...@alum.mit.edu]
> Sent: Monday, June 17, 2019 10:48 PM
> To: Roni Even (A); 'NABIL BENAMAR'; 'Roni Even'
> Cc: gen-art@ietf.org; 'IETF Discussion'; 
> i...@ietf.org; 
> draft-ietf-ipwave-ipv6-over-80211ocb@ietf.org
> Subject: RE: [ipwave] [Gen-art] Genart last call review of 
> draft-ietf-ipwave-ipv6-over-80211ocb-46
> 
> 
> 
> 
> From: its [mailto:its-boun...@ietf.org] On Behalf Of Roni Even (A)
> Sent: Monday, June 17, 2019 6:26 AM
> To: NABIL BENAMAR; Roni Even
> Cc: gen-art@ietf.org; IETF Discussion; 
> i...@ietf.org; 
> draft-ietf-ipwave-ipv6-over-80211ocb@ietf.org
> Subject: Re: [ipwave] [Gen-art] Genart last call review of 
> draft-ietf-ipwave-ipv6-over-80211ocb-46
> 
> Thanks,
> The only comment left is:
> 
> 2. In section 5.2 "The policy dictating when the MAC address is changed on the
> 802.11-OCB interface is to-be-determined.". Reading the next sentence it looks
> to me that this is needed as part of the solution and should not be left for
> the unknown future.
> 
> Should we reformulate here?
> 
> I was expecting some recommendation since the changing of MAC address is 
> important to address privacy issues (discussed in section 5). Currently it is 
> left open with no recommendation , only saying that dynamic change of MAC 
> address is needed.
> Maybe the document should have some normative language for example in section 
> 5.1 that will say that IP-OBU MUST dynamic change their MAC addresses
> [RR] I highly recommend AGAINST this!  There will be a number OBU and RSU 
> implementations that DO NOT require anonymity, and don't want it either.  
> Furthermore, immutable identifier change must be coordinated with all other 
> interfaces and protocols otherwise changing them is useless.
> 
> Did the document go through security area review?
> [RR] If it did, and the above was not mentioned, then something was missed.
> 
> Roni
> 
> 
> From: Gen-art [mailto:gen-art-boun...@ietf.org] On Behalf Of NABIL BENAMAR
> Sent: Monday, June 17, 2019 12:48 PM
> To: Roni Even
> Cc: gen-art@ietf.org; IETF Discussion; 
> i...@ietf.org; 
> draft-ietf-ipwave-ipv6-over-80211ocb@ietf.org
> Subject: Re: [Gen-art] 

Re: [Gen-art] [GROW] Genart last call review of draft-ietf-grow-wkc-behavior-03

[Brian E Carpenter]

On 05-May-19 06:03, Randy Bush wrote:
>> In my opinion, this document adds new requirements or at least new
>> considerations for implementations of RFC1997, I think that means it
>> updates RFC1997. I liked to see it have "Updates: 1997" metadata added and
>> appropriate statements in the Abstract and Intro. I think this requires and
>> justifies it being Standards Track.

That's a consistent approach too. One or the other, I don't care.

But not magenta, never!

Brian
>>
>> In both the Abstract and the 2nd paragraph of the Introduction,
> 
> i have no dog in this fight.  in general, i try to focus on the protein
> of the document, and leave grammar tweaks, what form of 2119 to use,
> etc. to the rfc editor, and weighty decisions such as this to the iesg.
> 
> the bikeshed will, of course, be magenta comic sans :)
> 
> randy
> 

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

Re: [Gen-art] [lisp] Genart last call review of draft-ietf-lisp-rfc8113bis-01

[Brian E Carpenter]

Hi Med,

That looks fine to me. Thanks!

Regards
   Brian Carpenter

On 2019-01-10 20:42, mohamed.boucad...@orange.com wrote:
> Hi Brian, all,
> 
> The changes are now available online: 
> https://tools.ietf.org/html/draft-ietf-lisp-rfc8113bis-02 
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-lisp-rfc8113bis-02
> 
> Cheers,
> Med
> 
>> -Message d'origine-
>> De : mohamed.boucad...@orange.com [mailto:mohamed.boucad...@orange.com]
>> Envoyé : vendredi 21 décembre 2018 07:57
>> À : Dino Farinacci; Brian E Carpenter
>> Cc : Joel M. Halpern; gen-art@ietf.org; l...@ietf.org; draft-ietf-lisp-
>> rfc8113bis@ietf.org
>> Objet : RE: [lisp] Genart last call review of draft-ietf-lisp-rfc8113bis-01
>>
>> Re-,
>>
>> Seems we are all in agreement.
>>
>> I implemented the changes to 8113bis in my local copy.
>>
>> Thank you, Brian.
>>
>> Cheers,
>> Med
>>
>>> -Message d'origine-
>>> De : Dino Farinacci [mailto:farina...@gmail.com]
>>> Envoyé : vendredi 21 décembre 2018 00:29
>>> À : Brian E Carpenter
>>> Cc : Joel M. Halpern; BOUCADAIR Mohamed TGI/OLN; gen-art@ietf.org;
>>> l...@ietf.org; draft-ietf-lisp-rfc8113bis@ietf.org
>>> Objet : Re: [lisp] Genart last call review of draft-ietf-lisp-rfc8113bis-01
>>>
>>>> On 2018-12-21 09:18, Dino Farinacci wrote:
>>>>> Brian wants to drop the reference to 6833bis from 8113bis. I am fine
>> with
>>> that. That reference being at the top of the draft saying “Updates
>> 6833bis”.
>>> If we remove that, he may concur. Please confirm Brian (again).
>>>>
>>>> Yes, that would resolve my concern.
>>>
>>> Thanks.
>>>
>>>>> Like I have mentioned to you before, the IETF “Updates” lingo is
>> confusing
>>> and really not useful unless a draft replaces a previous draft. And this is
>>> not the case here.
>>>>
>>>> That's a debate for the RFC-interest list perhaps. IMHO the issue is that
>>> "Updates" sometimes means "Extends" and sometimes means "Modifies".
>>> "Obsoletes" sometimes also implies "Replaces", but that doesn't seem to
>>> create confusion.
>>>
>>> Then maybe those words should be used.
>>>
>>> Dino
>>>
>>>>
>>>> Thanks
>>>>   Brian
>>>>
>>>>>
>>>>> Dino
>>>>>
>>>>>> On Dec 20, 2018, at 11:58 AM, Joel M. Halpern 
>>> wrote:
>>>>>>
>>>>>> Dino, Med, please confirm if I am reading the thread properly:
>>>>>>
>>>>>> I believe that the proposal is to make the small change below to
>> 6833bis
>>> and to drop the "updates" reference from 8113bis to 6833bis.
>>>>>>
>>>>>> I believe Dino's question was whether Brian agreed that the combination
>>> suggested would address his concern.
>>>>>>
>>>>>> Yours,
>>>>>> Joel
>>>>>>
>>>>>> On 12/20/18 2:55 PM, Brian E Carpenter wrote:
>>>>>>> I may be missing something but I don't see how 8113bis can
>>>>>>> logically cite 8113, which it replaces.
>>>>>>> Frankly I think you've collectively created a plate of citation
>>>>>>> spaghetti by not moving the IANA considerations for the type field
>>>>>>> registry into 6830bis, which is where they naturally belong. If you
>>>>>>> don't want to do that, I think you have to leave them in 8113bis and
>>>>>>> simply lose the citation of 6833bis, which serves no purpose that
>>>>>>> I can see.
>>>>>>> Regards
>>>>>>>   Brian
>>>>>>> On 2018-12-21 06:32, Dino Farinacci wrote:
>>>>>>>> I’ll make that change if Brian thinks it fixes the issues he raised.
>>>>>>>>
>>>>>>>> Dino
>>>>>>>> ngo
>>>>>>>>> On Dec 19, 2018, at 11:35 PM, 
>>>  wrote:
>>>>>>>>>
>>>>>>>>> Hi Dino,
>>>>>>>>>
>>>>>>>>> OLD:
>>>>>>>>>
>>>>>>>>>  Values in the "Not Assigned" range can be ass

Re: [Gen-art] [lisp] Genart last call review of draft-ietf-lisp-rfc8113bis-01

[Brian E Carpenter]

On 2018-12-21 09:18, Dino Farinacci wrote:
> Brian wants to drop the reference to 6833bis from 8113bis. I am fine with 
> that. That reference being at the top of the draft saying “Updates 6833bis”. 
> If we remove that, he may concur. Please confirm Brian (again).

Yes, that would resolve my concern.

> Like I have mentioned to you before, the IETF “Updates” lingo is confusing 
> and really not useful unless a draft replaces a previous draft. And this is 
> not the case here.

That's a debate for the RFC-interest list perhaps. IMHO the issue is that 
"Updates" sometimes means "Extends" and sometimes means "Modifies". "Obsoletes" 
sometimes also implies "Replaces", but that doesn't seem to create confusion.

Thanks
   Brian

> 
> Dino
> 
>> On Dec 20, 2018, at 11:58 AM, Joel M. Halpern  wrote:
>>
>> Dino, Med, please confirm if I am reading the thread properly:
>>
>> I believe that the proposal is to make the small change below to 6833bis and 
>> to drop the "updates" reference from 8113bis to 6833bis.
>>
>> I believe Dino's question was whether Brian agreed that the combination 
>> suggested would address his concern.
>>
>> Yours,
>> Joel
>>
>> On 12/20/18 2:55 PM, Brian E Carpenter wrote:
>>> I may be missing something but I don't see how 8113bis can
>>> logically cite 8113, which it replaces.
>>> Frankly I think you've collectively created a plate of citation
>>> spaghetti by not moving the IANA considerations for the type field
>>> registry into 6830bis, which is where they naturally belong. If you
>>> don't want to do that, I think you have to leave them in 8113bis and
>>> simply lose the citation of 6833bis, which serves no purpose that
>>> I can see.
>>> Regards
>>>Brian
>>> On 2018-12-21 06:32, Dino Farinacci wrote:
>>>> I’ll make that change if Brian thinks it fixes the issues he raised.
>>>>
>>>> Dino
>>>> ngo 
>>>>> On Dec 19, 2018, at 11:35 PM,  
>>>>>  wrote:
>>>>>
>>>>> Hi Dino,
>>>>>
>>>>> OLD:
>>>>>
>>>>>   Values in the "Not Assigned" range can be assigned according to
>>>>>   procedures in [RFC8126].
>>>>>
>>>>> NEW:
>>>>>
>>>>>   Values in the "Not Assigned" range can be assigned via Standards
>>>>>   Action [RFC8113].
>>>>>
>>>>> Cheers,
>>>>> Med
>>>>>
>>>>>> -Message d'origine-
>>>>>> De : Dino Farinacci [mailto:farina...@gmail.com]
>>>>>> Envoyé : mercredi 19 décembre 2018 19:00
>>>>>> À : BOUCADAIR Mohamed TGI/OLN
>>>>>> Cc : Joel M. Halpern; Brian E Carpenter; gen-art@ietf.org; l...@ietf.org;
>>>>>> draft-ietf-lisp-rfc8113bis@ietf.org
>>>>>> Objet : Re: [lisp] Genart last call review of 
>>>>>> draft-ietf-lisp-rfc8113bis-01
>>>>>>
>>>>>> What does fixing in (1) mean?
>>>>>>
>>>>>> Dino
>>>>>>
>>>>>>> On Dec 19, 2018, at 3:51 AM, 
>>>>>>  wrote:
>>>>>>>
>>>>>>> Hi all,
>>>>>>>
>>>>>>> Brian, whether to maintain the document standalone was discussed by the 
>>>>>>> WG.
>>>>>> You may refer, for example, to the message from Deborah which clarifies 
>>>>>> this
>>>>>> point: https://www.ietf.org/mail-archive/web/lisp/current/msg07886.html. 
>>>>>> One
>>>>>> of the outcomes of that discussion is to add an "updates" header to 
>>>>>> 8113bis.
>>>>>>>
>>>>>>> FWIW, one of the issues that led to that conclusion was whether to cite
>>>>>> rfc8113bis as normative in 6833bis (the approach I initially supported) 
>>>>>> and
>>>>>> agreed by Dino (https://www.ietf.org/mail-
>>>>>> archive/web/lisp/current/msg07882.html). Deborah convinced me that citing
>>>>>> 8113bis will lead to circular dependency. Which is a fair argument.
>>>>>>>
>>>>>>> The "updates" tag was justified as follows:
>>>>>>>
>>>>>>> (1)
>>>>>>>
>>>>>>> RFC683

Re: [Gen-art] [lisp] Genart last call review of draft-ietf-lisp-rfc8113bis-01

[Brian E Carpenter]

I may be missing something but I don't see how 8113bis can
logically cite 8113, which it replaces.

Frankly I think you've collectively created a plate of citation
spaghetti by not moving the IANA considerations for the type field
registry into 6830bis, which is where they naturally belong. If you
don't want to do that, I think you have to leave them in 8113bis and
simply lose the citation of 6833bis, which serves no purpose that
I can see.

Regards
   Brian

On 2018-12-21 06:32, Dino Farinacci wrote:
> I’ll make that change if Brian thinks it fixes the issues he raised.
> 
> Dino
> 
>> On Dec 19, 2018, at 11:35 PM,  
>>  wrote:
>>
>> Hi Dino, 
>>
>> OLD: 
>>
>>   Values in the "Not Assigned" range can be assigned according to
>>   procedures in [RFC8126].
>>
>> NEW:
>>
>>   Values in the "Not Assigned" range can be assigned via Standards
>>   Action [RFC8113].
>>
>> Cheers,
>> Med
>>
>>> -Message d'origine-
>>> De : Dino Farinacci [mailto:farina...@gmail.com]
>>> Envoyé : mercredi 19 décembre 2018 19:00
>>> À : BOUCADAIR Mohamed TGI/OLN
>>> Cc : Joel M. Halpern; Brian E Carpenter; gen-art@ietf.org; l...@ietf.org;
>>> draft-ietf-lisp-rfc8113bis@ietf.org
>>> Objet : Re: [lisp] Genart last call review of draft-ietf-lisp-rfc8113bis-01
>>>
>>> What does fixing in (1) mean?
>>>
>>> Dino
>>>
>>>> On Dec 19, 2018, at 3:51 AM, 
>>>  wrote:
>>>>
>>>> Hi all,
>>>>
>>>> Brian, whether to maintain the document standalone was discussed by the WG.
>>> You may refer, for example, to the message from Deborah which clarifies this
>>> point: https://www.ietf.org/mail-archive/web/lisp/current/msg07886.html. One
>>> of the outcomes of that discussion is to add an "updates" header to 8113bis.
>>>>
>>>> FWIW, one of the issues that led to that conclusion was whether to cite
>>> rfc8113bis as normative in 6833bis (the approach I initially supported) and
>>> agreed by Dino (https://www.ietf.org/mail-
>>> archive/web/lisp/current/msg07882.html). Deborah convinced me that citing
>>> 8113bis will lead to circular dependency. Which is a fair argument.
>>>>
>>>> The "updates" tag was justified as follows:
>>>>
>>>> (1)
>>>>
>>>> RFC6833bis includes the following:
>>>>
>>>>  Values in the "Not Assigned" range can be assigned according to
>>>>  procedures in [RFC8126].
>>>>
>>>> That text is updated by RFC8113bis to be aligned with 8113:
>>>>
>>>>  Values can be assigned via Standards Action
>>>>
>>>> (2)
>>>>
>>>> RFC8113bis extends the type field to grab more bits/values when the
>>> available types are exhausted. This is captured in 8113bis:
>>>>
>>>>  The values in the range 0-1023 are assigned via Standards Action.
>>>>  This range is provisioned to anticipate, in particular, the
>>>>  exhaustion of the LISP Packet types.
>>>>
>>>> Dino: If (1) is fixed directly in RFC6833bis, then I'm fine to remove the
>>> "updates" header because (2) can be also seen as an extension.
>>>>
>>>> Cheers,
>>>> Med
>>>>
>>>>> -Message d'origine-
>>>>> De : Dino Farinacci [mailto:farina...@gmail.com]
>>>>> Envoyé : mercredi 19 décembre 2018 06:37
>>>>> À : Joel M. Halpern
>>>>> Cc : Brian E Carpenter; gen-art@ietf.org; l...@ietf.org; draft-ietf-lisp-
>>>>> rfc8113bis@ietf.org
>>>>> Objet : Re: [lisp] Genart last call review of draft-ietf-lisp-rfc8113bis-
>>> 01
>>>>>
>>>>> Mohmad to comment.
>>>>>
>>>>> Dino
>>>>>
>>>>>> On Dec 18, 2018, at 8:49 PM, Joel M. Halpern  
>>>>>> wrote:
>>>>>>
>>>>>> That is the other fix he offered.  Just remove the updates tag.
>>>>>> I will leav eit to you and the the authors to determine which is correct.
>>>>>> Yours,
>>>>>> Joel
>>>>>>
>>>>>> On 12/18/18 11:43 PM, Dino Farinacci wrote:
>>>>>>> 8113bis should say that is it *extending* the type field so we can have
>>>>> more types. The word “update” I always had a problem with because it can
&

Re: [Gen-art] Genart last call review of draft-ietf-lisp-rfc8113bis-01

[Brian E Carpenter]

On 2018-12-19 15:46, Joel M. Halpern wrote:
> This is part of the package to move the coherent set of base LISP specs 
> to PS.
> 
> The reason we did this rather than folding it into 6830bis / 6833bis is 
> that we had originally simply cited 8113, and then realized that needed 
> to move to PS along with everything else.  It seemed (and is) simpler to 
> do it separately rather than to further modify 6830bis / 6933bis.
> 
> As for why it updates 6833bis, that is because one of the cahnges in 
> moving the set to PS was to improve the split as to which information 
> belonged in which document.

OK, but I still don't find it logical The text doesn't explain which part of
6833bis is impacted, and normally these days we require such an explanation.
And if there is an impact, you're missing the opportunity of fixing the error
or gap in 6833bis, so the reader of 6833bis will be none the wiser unless
you insert a reference to 8113bis.

On the other hand, if there is no error or gap, you don't need "Updates:"
at all. (Unfortunately, we don't have an "Extends:" header.)

   Brian

> 
> Yours,
> Joel
> 
> On 12/18/18 9:25 PM, Brian Carpenter wrote:
>> Reviewer: Brian Carpenter
>> Review result: Ready with Issues
>>
>> Gen-ART Last Call review of draft-ietf-lisp-rfc8113bis-01
>>
>> 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-lisp-rfc8113bis-01.txt
>> Reviewer: Brian Carpenter
>> Review Date: 2018-12-19
>> IETF LC End Date: 2018-12-27
>> IESG Telechat date:
>>
>> Summary: Ready with issues
>> 
>>
>> Comments:
>> -
>>
>> I note that this is being raised from Experimental to the standards track.
>> Presumably that depends on the base LISP spec becoming PS.
>>
>> Minor issues:
>> -
>>
>> "This document updates I-D.ietf-lisp-rfc6833bis." The text doesn't
>> explain which text is updated. This is in contrast to RFC8113, which
>> explains clearly how it updates RFC6830 (*not* RFC6833). Why doesn't
>> this draft claim to update rfc6830bis? I'm going to assume that
>> is an error.
>>
>> In fact, why wasn't the definition of the LISP Packet Types registry
>> moved into the base spec (rfc6830bis)? That is where it belongs.
>>
>> Since rfc6830bis (and rfc6833bis) are still under IESG review, anything
>> in them that needs updating should be updated! The fact is that rfc8113bis
>> extends rfc6830bis, which is not the same thing as "updates".
>> If the WG thinks that implementers of 6830bis need to read 8113bis,
>> there should be a normative reference in 6830bis to 8113bis.
>>
>>
> 

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

Re: [Gen-art] dealing with many the secdir and genart comments [on draft-ietf-anima-bootstrapping-keyinfra]

[Brian E Carpenter]

On 2018-11-30 11:36, Michael Richardson wrote:
> 
> {This is the first of many replies to the various reviews}
> 
> Jari Arkko  wrote:
>> My first bigger comment is that I believe the security and privacy
>> considerations section should have provided an actual in-depth
>> analysis of the characteristics offered by the protocol, perhaps under
>> several different situations, as the protocol can be operated in
>> different modes.
> 
> The authors seriously believe that this will result in an attempt to boil the
> ocean.  Yes, BRSKI is exciting for many and opens many doors, but in
> the context of the *ANIMA* Charter, we strongly think that this
> document should leave the oceans alone, and deal only with the
> ANIMA ACP usage.

Yes, violent agreement. From all the interest outside ANIMA, the basic
idea of BRSKI is a big hit and will be re-used in other contexts. I think
a strong statement about the specific scope of *this* document belongs
in the Abstract and Introduction, with a comment that variant usages
of BRSKI in other scenarios will be documented separately.
 
> Other users of BRSKI *SHOULD* write a new profile.
> Would it be acceptable for us to provide a section that might be
> entitled:
> "The ACP mode of operation of BRSKI"
> 
> or perhaps some other section that would clarify the applicability of this
> document?

That too, but make sure that the reader gets the point in the first
few seconds of reading.

> 
> We would list the assumptions and maybe even reduce the options for use
> in the ACP?
> 
> The authors do not object to writing more documents about more situations
> where BRSKI might be used, but we think that putting it all into one
> document is a way for continuing scope creep.
> 
> In accepting the constrained work into the ANIMA WG, the chairs and area
> director have already been very generous.
> 
>> My second comment is that the protocol as defined is quite focused on
>> manufacturer-controlled situations. As Christian mentioned, there is
>> some discussion of other situations in the document (Section 6.4), but
>> not much, and there's little information on what happens if one tries
>> to use the protocol in this way.
> 
> The above comments would seem to apply to this as well.

Correct. The last call discussion has convinced me for one that we need
to tackle the issue of non-MASA scenarios, and I have some ideas about
it, but *the scope of this document* is MASA-based scenarios for
professionally managed networks. Let's make that clear (see above)
but not dilute the present text with it.

   Brian

> 
> As I previously indicated when you first wrote this, we have turned your
> comments into a series of issues on github, and we will be closing those
> issues as quickly as we can.
> 
> Some will come with proposed text changes, but a number will need discussion,
> and we will start new subject lines in this thread for them.   I don't want
> to innudate you, so I've set the Reply-To.
> 
> --
> ]   Never tell me the odds! | ipv6 mesh networks [
> ]   Michael Richardson, Sandelman Software Works| network architect  [
> ] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails
> [
> 
> 
> --
> Michael Richardson , Sandelman Software Works
>  -= IPv6 IoT consulting =-
> 
> 
> 
> 
> ___
> Gen-art mailing list
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art
> 

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

Re: [Gen-art] Genart telechat review of draft-ietf-anima-reference-model-08

[Brian E Carpenter]

Joel,

On 2018-10-12 15:17, Joel Halpern wrote:


> Nits/editorial comments:
> The reference [IDevID] still appears to me to be a normative reference.

It is normative in draft-ietf-anima-bootstrapping-keyinfra, where it really 
matters. Seems like a marginal point in an Informational document, but of course
we'll follow the IESG's guidance.

>In 3.3.3, the new parenthetical e.g. (replacing the wording "For example",
>seems to have no closing parenthesis.

Ack.

Thanks
 Brian

___
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-bess-mvpn-expl-track-10

[Brian E Carpenter]

Hi Eric,

On 2018-10-05 04:15, Eric Rosen wrote:
>> Minor issues:
>> -
>>
>> As I understand it, if a network only partially supports the new
>> (LIR-pF) flag, it doesn't work properly. So we find at the end of
>> section 2:
>>
>> ...the ingress node can conclude
>> that the egress node originating that Leaf A-D route does not support
>> the LIR-pF flag.
>>
>> The software at the ingress node SHOULD detect this, and should have
>> a way of alerting the operator that the deployment is not properly
>> configured.
>>
>> I don't see why this is only a SHOULD, and I don't see why the operator
>> alert is not a MUST too. Surely the operator always needs to be alerted?
> 
> Good point, I have changed this to:
> 
>     The software at the ingress node MUST detect this, and MUST have a 
> way of alerting the operator that the deployment is not properly configured.

Thanks.
 
>> I agree with the point raised in the Routing Area review
>> (be explicit about the updated sections of RFC 6514, 6625,
>> and 7524).
> 
> The clarifications and extensions may affect the procedures for 
> originating and receiving/processing S-PMSI A-D routes and Leaf A-D 
> routes.  These procedures are discussed in many different places in the 
> updated drafts.  

Fair enough. I suggest adding a version of those two sentences in the
Introduction. Otherwise you can bet on this point being raised by the
IESG anyway.

Regards
Brian

> I don't believe there is any value in having the 
> authors of mvpn-expl-track go through those drafts to try to make a list 
> of all the places where S-PMSI A-D routes and/or Leaf A-D routes are 
> discussed.  If we attempted to do so, we'd surely miss a few places and 
> thereby introduce bugs into the spec.  The information currently in the 
> document is sufficient to enable anyone who understands the updated 
> references to figure out what needs to be done.




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

Re: [Gen-art] [Softwires] Genart last call review of draft-ietf-softwire-mesh-multicast-22

[Brian E Carpenter]

On 2018-09-17 19:01, Ole Troan wrote:
>> No, it isn't, but as far as I can see, any tunnel spec needs to state how 
>> this applies. If the tunnel keeps no packet state, how is it going to 
>> perform PMTUD? If the answer is that the tunnel end points need to be 
>> configured in some way, that needs to be stated too.
>>
>> Sorry to go on, but when I review a draft, I like to feel that if I had to, 
>> I could code it, and in this case I just don't know how I would code the 
>> AFBR with respect to PMTUD and/or including a fragment header.
> 
> Typically tunnels are either configured with a fixed MTU, or do path MTU 
> discovery like any other host on the Internet.
> E.g. for a point to point tunnel it can dynamically set the MTU on a tunnel 
> interface based on received PMTUD messages (or PLMTUD probing).
> For point to multi-point tunnels it maintains a PMTUD cache.
> There’s no magic for tunnels here, just like Joe says.

No, of course not. But the implementor has to do something, and I don't see
how this can be an interoperable specification without some guidance
for the AFBR implementor.

Since there is implementation experience, it shouldn't be hard to provide
such guidance.

Brian

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

Re: [Gen-art] [Softwires] Genart last call review of draft-ietf-softwire-mesh-multicast-22

[Brian E Carpenter]

On 2018-09-17 10:28, Joe Touch wrote:
> Hi, Brian,
> 
>> On Sep 16, 2018, at 1:44 PM, Brian E Carpenter  
>> wrote:
>>
>> Hi Joe,
>> On 2018-09-17 05:15, Joe Touch wrote:
>>> Hi, Brian,
>>>
>>> See comments below…
>>>
>>> Joe
>>>
>>>> On Sep 15, 2018, at 3:32 PM, Brian E Carpenter 
>>>>  wrote:
>>>>
>>>> Dear 杨术,
>>>>
>>>> I have added Joe Touch in Cc because one point below overlaps
>>>> with his TSVART review.
>>>> On 2018-09-16 06:41, 杨术 wrote:
>>>>> Dear Brian,
>>>>>
>>>>> Thank you very much for your comments, the following is the response,  
>>>>>
>>>>>> “One of the authors (Shu Yang) stated that the Bitway company (a 
>>>>>> networking 
>>>>>> device company in China) have implemented a prototype."
>>>>>> Note that the -00 draft was published in 2011. Not exactly fast progress
>>>>>> in the market.
>>>>>
>>>>> We have made more progress in these years, Bitway has already implemented 
>>>>>  
>>>>> it and deployed it in about 100 universities in CERNET2.
>>>>
>>>> That's good to know. (I like the concept of an Implementation Status
>>>> section as described in RFC7942, and I wish that all WGs would use this.)
>>>>
>>>> Now back to the fragmentation issue. Thank you for the new text:
>>>>
>>>> 7.3.  Fragmentation
>>>>
>>>>  The encapsulation performed by an upstream AFBR will increase the
>>>>  size of packets.  As a result, the outgoing I-IP link MTU may not
>>>>  accommodate the larger packet size.  It is not always possible for
>>>>  core operators to increase the MTU of every link, thus fragmentation
>>>>  after encapsulation and reassembling of encapsulated packets MUST be
>>>>  supported by AFBRs [RFC5565].  The specific requirements for
>>>>  fragmentation and tunnel configuration COULD be referred to in
>>>>  [I-D.ietf-intarea-tunnels], which is under revision currently.
>>>>
>>>> One of my problems remains, and is not answered by 
>>>> draft-ietf-intarea-tunnels:
>>>>
>>>>>> But more seriously, if I-IP is IPv6, how does the originator of the IPv6
>>>>>> packet (the AFBR) know that it needs to include a fragment header?
>>>>>> Is there some kind of hidden PMTUD process, or is this configured?
>>>>>
>>>>>> (I assume we are not so interested in the case that I-IP is IPv4, but
>>>>>> then the issue is that the AFBR MUST NOT set the DF bit.)
>>>>
>>>> draft-ietf-intarea-tunnels does cover the setting of DF, but it still
>>>> doesn't state how the tunnel end point knows when to include an IPv6
>>>> fragment header, unless I missed something.
>>>
>>> If IPv6 fragmentation is needed, then the frag header is included. 
>>> Otherwise, it is not. As per the standard. 
>>
>> Yes, but my question is: How does the AFBR (the IPv6 source node) *know*
>> that fragmentation is needed?
> 
> Path MTU discovery for the tunnel - at worst, based on the tunnel interface 
> MTU. This is discussed in Section 4.2.3 of the draft-ietf-intarea-tunnels.
> 
>> This question doesn't arise for IPv4;
>> if you don't set DF, you don't need to worry about PMTU size.
> 
> For IPv4 as an outer header, yes - but see RFC 6864. Clearing DF means the 
> tunnel ingress MUST generate new packets at a rate where it can ensure the IP 
> IDs don’t cycle where fragments overlap (which is also already discussed in 
> the section indicated above.
> 
>>
>>> There’s no “DF” in IPv6 because on-path fragmentation isn’t possible.
>>
>> Exactly, so the absence of a fragment header forbids it.
> 
> No, IPv6 forbids on-path fragmentation of an existing header only. The IPv6 
> tunnel encapsulation header isn’t on-path per se; it’s completely valid to 
> encapsulate a received IPv6 packet inside an IPv6 tunnel that fragments *at 
> the outer layer* (i.e., reassembling at the tunnel egress). 
> 
>> So should
>> the AFBR include a frag header just in case?
> 
> That won’t help. The frag header would be generated at the tunnel ingress and 
> has to be unique there (which has no relation to a frag header of the inner 
> packet, if one is present).

Yes to the above, but as I understand the draft, the AFBR *is* the tun

Re: [Gen-art] [Softwires] Genart last call review of draft-ietf-softwire-mesh-multicast-22

[Brian E Carpenter]

Hi Joe,
On 2018-09-17 05:15, Joe Touch wrote:
> Hi, Brian,
> 
> See comments below…
> 
> Joe
> 
>> On Sep 15, 2018, at 3:32 PM, Brian E Carpenter  
>> wrote:
>>
>> Dear 杨术,
>>
>> I have added Joe Touch in Cc because one point below overlaps
>> with his TSVART review.
>> On 2018-09-16 06:41, 杨术 wrote:
>>> Dear Brian,
>>>
>>> Thank you very much for your comments, the following is the response,  
>>>
>>>> “One of the authors (Shu Yang) stated that the Bitway company (a 
>>>> networking 
>>>> device company in China) have implemented a prototype."
>>>> Note that the -00 draft was published in 2011. Not exactly fast progress
>>>> in the market.
>>>
>>> We have made more progress in these years, Bitway has already implemented  
>>> it and deployed it in about 100 universities in CERNET2.
>>
>> That's good to know. (I like the concept of an Implementation Status
>> section as described in RFC7942, and I wish that all WGs would use this.)
>>
>> Now back to the fragmentation issue. Thank you for the new text:
>>
>> 7.3.  Fragmentation
>>
>>   The encapsulation performed by an upstream AFBR will increase the
>>   size of packets.  As a result, the outgoing I-IP link MTU may not
>>   accommodate the larger packet size.  It is not always possible for
>>   core operators to increase the MTU of every link, thus fragmentation
>>   after encapsulation and reassembling of encapsulated packets MUST be
>>   supported by AFBRs [RFC5565].  The specific requirements for
>>   fragmentation and tunnel configuration COULD be referred to in
>>   [I-D.ietf-intarea-tunnels], which is under revision currently.
>>
>> One of my problems remains, and is not answered by 
>> draft-ietf-intarea-tunnels:
>>
>>>> But more seriously, if I-IP is IPv6, how does the originator of the IPv6
>>>> packet (the AFBR) know that it needs to include a fragment header?
>>>> Is there some kind of hidden PMTUD process, or is this configured?
>>>
>>>> (I assume we are not so interested in the case that I-IP is IPv4, but
>>>> then the issue is that the AFBR MUST NOT set the DF bit.)
>>
>> draft-ietf-intarea-tunnels does cover the setting of DF, but it still
>> doesn't state how the tunnel end point knows when to include an IPv6
>> fragment header, unless I missed something.
> 
> If IPv6 fragmentation is needed, then the frag header is included. Otherwise, 
> it is not. As per the standard. 

Yes, but my question is: How does the AFBR (the IPv6 source node) *know*
that fragmentation is needed? This question doesn't arise for IPv4;
if you don't set DF, you don't need to worry about PMTU size.

> There’s no “DF” in IPv6 because on-path fragmentation isn’t possible.

Exactly, so the absence of a fragment header forbids it. So should
the AFBR include a frag header just in case? Should this be
configurable? Should it use some form of PMTUD? Or do we require
the actual PMTU to be big enough?

I see this as a gap in the specification.

Question to the authors: what does the Bitway implementation do?
Does it include a fragment header, or is the MTU simply configured
to be big enough?

   Brian

> 
>> I'm not sure whether this
>> needs discussion in the present draft or in Joe's draft, which is why
>> I added the Cc.
>>
>> Also I feel that the reference to draft-ietf-intarea-tunnels
>> should be normative, because I think an implementor needs to get
>> this right.
> 
> Draft-ietf-intarea-tunnels is currently slated for BCP, not standards-track. 
> I don’t recall if that matters for standards-track docs or whether it’s 
> considered a down-ref.
> 
> Joe
> 
> 

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

Re: [Gen-art] [Softwires] Genart last call review of draft-ietf-softwire-mesh-multicast-22

[Brian E Carpenter]

Dear 杨术,

I have added Joe Touch in Cc because one point below overlaps
with his TSVART review.
On 2018-09-16 06:41, 杨术 wrote:
> Dear Brian,
>  
> Thank you very much for your comments, the following is the response,  
>  
>> “One of the authors (Shu Yang) stated that the Bitway company (a networking 
>> device company in China) have implemented a prototype."
>> Note that the -00 draft was published in 2011. Not exactly fast progress
>> in the market.
>  
> We have made more progress in these years, Bitway has already implemented  
> it and deployed it in about 100 universities in CERNET2.

That's good to know. (I like the concept of an Implementation Status
section as described in RFC7942, and I wish that all WGs would use this.)

Now back to the fragmentation issue. Thank you for the new text:

7.3.  Fragmentation

   The encapsulation performed by an upstream AFBR will increase the
   size of packets.  As a result, the outgoing I-IP link MTU may not
   accommodate the larger packet size.  It is not always possible for
   core operators to increase the MTU of every link, thus fragmentation
   after encapsulation and reassembling of encapsulated packets MUST be
   supported by AFBRs [RFC5565].  The specific requirements for
   fragmentation and tunnel configuration COULD be referred to in
   [I-D.ietf-intarea-tunnels], which is under revision currently.

One of my problems remains, and is not answered by draft-ietf-intarea-tunnels:

>> But more seriously, if I-IP is IPv6, how does the originator of the IPv6
>> packet (the AFBR) know that it needs to include a fragment header?
>> Is there some kind of hidden PMTUD process, or is this configured?
>  
>> (I assume we are not so interested in the case that I-IP is IPv4, but
>> then the issue is that the AFBR MUST NOT set the DF bit.)

draft-ietf-intarea-tunnels does cover the setting of DF, but it still
doesn't state how the tunnel end point knows when to include an IPv6
fragment header, unless I missed something. I'm not sure whether this
needs discussion in the present draft or in Joe's draft, which is why
I added the Cc.

Also I feel that the reference to draft-ietf-intarea-tunnels
should be normative, because I think an implementor needs to get
this right.

...
 
>>> "9.  Softwire Mesh Multicast Encapsulation
>>>  
>>> Softwire mesh multicast encapsulation does not require the use of any
>>> one particular encapsulation mechanism.  Rather, it MUST accommodate
>>> a variety of different encapsulation mechanisms, and allow the use of
>>> encapsulation mechanisms mentioned in [RFC4925].  Additionally, all
>>> of the AFBRs attached to the I-IP network MUST implement the same
>>> encapsulation mechanism."
>>  
>> It isn't clear how this is achieved. Presumably it needs to be configured
>> in each AFBR? An operator needs to manage this somehow or other.
>  
> Again, we add a pointer to draft-ietf-intarea-tunnel, which discuss about  
> tunnel, fragmentation, ttl in more details.

True, but it does not answer my question. In the specific case
of softwire-mesh-multicast, how is that "MUST" achieved?
Perhaps all you need to say is:

  Additionally, all
  of the AFBRs attached to the I-IP network MUST be configured
  to use the same encapsulation mechanism.  
>> "(S,G) state" is a term of art that is not defined here, or in the
>> reference [RFC7899]. I think there should be a reference to [RFC7761]
>> where "(S,G) state" is first used; or define it in the Terminology
>> section.
>  
> We add a reference to [RFC7761] each time when (S,G), (*, G), (S,G,rpt) 
> is first used.

Thanks!

Brian

___
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-sidrops-ov-clarify-03

[Brian E Carpenter]

On 31/07/2018 13:35, Randy Bush wrote:
> thanks for review!
> 
>> Title would be more searchworthy if it read "BGP-4 Origin Validation 
>> Clarifications"
> 
> ok.  how about "BGP-4 RPKI-Based Origin Validation Clarifications?"

Sure

   Brian

> 
>> Abstract:  s/\"/./
> 
> whoopsie.
> 
> will keep new xml in in emacs buffer until all reviews are in
> 
> randy
> 

___
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-pals-ethernet-cw-06

[Brian E Carpenter]

Hi Stewart,

On 02/07/2018 22:19, Stewart Bryant wrote:
> Hi Brian
> 
> Thank you for your review comments. Please see inline.
> 
> On 12/06/2018 04:30, Brian Carpenter wrote:
>> Reviewer: Brian Carpenter
>> Review result: Ready with Nits
>>
>> Gen-ART Last Call review of draft-ietf-pals-ethernet-cw-06
>>
>> 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-pals-ethernet-cw-06.txt
>> Reviewer: Brian Carpenter
>> Review Date: 2018-06-12
>> IETF LC End Date: 2018-06-15
>> IESG Telechat date: 2018-06-21
>>
>> Summary: Ready with nits
>> 
>>
>> Comments:
>> -
>>
>> This (with RFC4928) is a wonderful example of why layer violations are a Bad 
>> Thing.
>>
>> Nits:
>> -
>>
>>> 1.  Introduction
>> ...
>>>This document recommends the use of the Ethernet pseudowire control
>>>word in all but exceptional circumstances.
>> That's wrong, it *mandates* this usage with a MUST (first paragraph of 
>> section 4).
> 
> The text with the MUST is
> 
> "This document updates {{RFC4448}} to state that
> where both the ingress PE and the egress PE support the Ethernet
> pseudowire control word, then the CW MUST be used."
> 
> This is conditional on both equipments supporting the feature.
> 
> During WG discussion there was a lot of discussion on the degree to
> which we would mandate the migration to CW.  The problem is that
> the use of the CW has hardware implications. At one stage we went
> so far as to recommend the the phasing out of equipment that could
> not support the CW, but we got strong pushback from a specialist part
> of the vendor community. This led us to a compromise position where
> we RECOMMEND the use of the CW, but only  mandate that the CW be
> used if it is available in the equipment used at both ends of
> the PW.

Fair enough, but the text doesn't quite say that.

OLD:
This document updates [RFC4448] to state that where both the
ingress PE and the egress PE support the Ethernet pseudowire control
word, then the CW MUST be used.

NEW:
This document updates [RFC4448] to state that both the
ingress PE and the egress PE SHOULD support the Ethernet
pseudowire control word, and that if supported the CW MUST be used.

Regards
Brian

> 
>>> 3.  Background
>> ...
>>>A recent posting on the Nanog email list has highlighted this
>>>problem:
>>>
>>>https://mailman.nanog.org/pipermail/nanog/2016-December/089395.html
>> No, it's no longer recent. How about:
>>
>> For example, a posting on the N email list highlighted this
>> problem:
> 
> I have changed the text to:
> 
> A posting on the NANOG email list highlighted this problem:
> 
> 
>>
>>> 7.  Operational Considerations
>>>
>>>CW presence on the PW is controlled by the configuration and may be
>>>subject to default operational mode of not being enabled.
>> That sentence is hard to parse. Try this:
>>
>> A configuration switch might determine whether the CW is used on the PW.
>> The default configuration might be to disable use of the CW.
> This now says:
> 
> In some cases, the inclusion of a CW in the PW is determined by
> equipment configuration. Furthermore, it is possible that the default
> configuration in such cases is  to disable use of the CW.
> 
> - Stewart
> 
> 

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

Re: [Gen-art] Genart telechat review of draft-ietf-6man-ndpioiana-02

[Brian E Carpenter]

On 01/05/2018 02:10, Ole Troan wrote:

>> 4. Section 4 - It would be good to capitalize Standards Action, and refer to
>> RFC 8126 as reference (also to be added)
> 
> Capitalisation done.
> I ended up leaning towards not referencing 8126. As most documents with IANA 
> considerations don't. To be consistent.

Really? As an author, I think I've always cited RFC8126 or its predecessors when
defining an assignment policy. "Standards Action" may be self-defining, but
certainly the more subtle policies like "Specification Required" need a 
reference.

   Brian

___
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-6tisch-6top-protocol-10

[Brian E Carpenter]

Hi,

The published -11 text is even better than the proposal below.

Thanks
   Brian Carpenter

On 23/03/2018 08:10, Brian E Carpenter wrote:
> That looks good to me. I think it will help implementers.
> 
> Thanks
>Brian Carpenter
> 
> On 22/03/2018 21:41, Xavi Vilajosana Guillen wrote:
>> Dear Brian,
>>
>> after the WG meeting we proceed to resolve your pointed issue. Thanks so
>> much for going through the draft again.
>>
>> We will publish v11 with the following update on the text as you suggested.
>> We hope this clarifies your point.
>>
>>
>> In section 3.1.1.  2-step 6P Transaction
>> we added:
>> Race conditions MAY happen when a timeout expires while a 6P
>>Response is on the air.  Other inconsistencies can also happen
>>when the last L2 ACK for a 6P Response is lost or when one of the
>>nodes is power cycled.  6P provides an inconsistency detection
>>mechanism described in Section 3.4.6.1 to cope with such
>>situations.
>>
>>
>> In section 3.1.2.  3-step 6P Transaction
>> we added:
>>   Race conditions MAY happen when a timeout expires while a 6P
>>Confirmation is on the air.  Other inconsistencies can also
>>happen when the last L2 ACK for a 6P Confirmation is lost or when
>>one of the nodes is power cycled.  6P provides an inconsistency
>>detection mechanism described in Section 3.4.6.1 to cope with
>>such situations.
>>
>>
>> kind regards
>> Xavi
>>
>>
>> 2018-03-11 4:11 GMT+01:00 Brian Carpenter <brian.e.carpen...@gmail.com>:
>>
>>> Reviewer: Brian Carpenter
>>> Review result: 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
>>>
>>> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
>>>
>>> Document: draft-ietf-6tisch-6top-protocol-10
>>> Reviewer: Brian Carpenter
>>> Review Date: 2018-03-10
>>> IETF LC End Date: 2018-03-26
>>> IESG Telechat date: 2018-04-05
>>>
>>> Summary: Ready
>>>
>>> Comment:
>>>
>>> Most of my previous comments have been fixed, thanks. I still disagree
>>> with the authors on one point, but not enough to delay the draft:
>>>
>>> In section 3.1.1 "2-step 6P Transaction" there seems to be a rare race
>>> condition
>>> if A's timeout expires while B's Response is in flight. This will be
>>> detected
>>> later as an inconsistency (section 3.4.6.2). The authors don't think it's
>>> necessary
>>> to mention this in 3.1.1. IMHO it would be useful to mention. (Similarly
>>> for
>>> section 3.1.2, 3-step transaction.)
>>>
>>>
>>>
>>
>>

___
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-6tisch-6top-protocol-10

[Brian E Carpenter]

That looks good to me. I think it will help implementers.

Thanks
   Brian Carpenter

On 22/03/2018 21:41, Xavi Vilajosana Guillen wrote:
> Dear Brian,
> 
> after the WG meeting we proceed to resolve your pointed issue. Thanks so
> much for going through the draft again.
> 
> We will publish v11 with the following update on the text as you suggested.
> We hope this clarifies your point.
> 
> 
> In section 3.1.1.  2-step 6P Transaction
> we added:
> Race conditions MAY happen when a timeout expires while a 6P
>Response is on the air.  Other inconsistencies can also happen
>when the last L2 ACK for a 6P Response is lost or when one of the
>nodes is power cycled.  6P provides an inconsistency detection
>mechanism described in Section 3.4.6.1 to cope with such
>situations.
> 
> 
> In section 3.1.2.  3-step 6P Transaction
> we added:
>   Race conditions MAY happen when a timeout expires while a 6P
>Confirmation is on the air.  Other inconsistencies can also
>happen when the last L2 ACK for a 6P Confirmation is lost or when
>one of the nodes is power cycled.  6P provides an inconsistency
>detection mechanism described in Section 3.4.6.1 to cope with
>such situations.
> 
> 
> kind regards
> Xavi
> 
> 
> 2018-03-11 4:11 GMT+01:00 Brian Carpenter :
> 
>> Reviewer: Brian Carpenter
>> Review result: 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-6tisch-6top-protocol-10
>> Reviewer: Brian Carpenter
>> Review Date: 2018-03-10
>> IETF LC End Date: 2018-03-26
>> IESG Telechat date: 2018-04-05
>>
>> Summary: Ready
>>
>> Comment:
>>
>> Most of my previous comments have been fixed, thanks. I still disagree
>> with the authors on one point, but not enough to delay the draft:
>>
>> In section 3.1.1 "2-step 6P Transaction" there seems to be a rare race
>> condition
>> if A's timeout expires while B's Response is in flight. This will be
>> detected
>> later as an inconsistency (section 3.4.6.2). The authors don't think it's
>> necessary
>> to mention this in 3.1.1. IMHO it would be useful to mention. (Similarly
>> for
>> section 3.1.2, 3-step transaction.)
>>
>>
>>
> 
> 

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

Re: [Gen-art] [6tisch] Genart telechat review of draft-ietf-6tisch-6top-protocol-09

[Brian E Carpenter]

Hi,
On 27/02/2018 05:31, Qin Wang wrote:
...
> [Qin] Add following textin both section 3.1.1 and 3.1.2
> In case a race conditionhappens during the communication, the TSCH schedule 
> of node A may becomeinconsistent with the TSCH schedule of node B. 6top 
> handles the schedule inconsistency in the way described in Section3.4.6.2

I don't think that made it into the -10 version.

Brian

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

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] [6tisch] Genart telechat review of draft-ietf-6tisch-6top-protocol-09

[Brian E Carpenter]

Thanks, those changes look good.

Regards
   Brian

On 27/02/2018 05:31, Qin Wang wrote:
> Hi Bian,
> Thank you for your comments. Please see inline.
> 
> 
> 
> On Friday, February 23, 2018 6:11 PM, Brian E Carpenter 
> <brian.e.carpen...@gmail.com> wrote:
>  
> 
>  Hi Qin, see in line:
> 
> On 24/02/2018 04:16, Qin Wang wrote:
>> Hi Brian,
>> Thank you very much for your comments. Please see inline.
>>
>> On Monday, February 19, 2018 6:22 PM, Brian Carpenter 
>> <brian.e.carpen...@gmail.com> wrote: 
>>
>>   Reviewer: Brian Carpenter
>> Review result: Ready with Issues
>>
>> Gen-ART Last Call review of draft-ietf-6tisch-6top-protocol-09
>>
>> 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
>> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
>>
>> Document: draft-ietf-6tisch-6top-protocol-09.txt
>> Reviewer: Brian Carpenter
>> Review Date: 2018-02-20
>> IETF LC End Date: 2018-??-??
>> IESG Telechat date: 2018-03-06
>>
>> Summary: Ready with issues
>> 
>>
>> Comment:
>> 
>>
>> This is a Last Call review despite the subject field. When will the Last
>> Call be started?
>>
>> Major issues:
>> -
>>
>> In section 3.1.1 "2-step 6P Transaction" there seems to be a race condition
>> if A's timeout expires while B's Response is in flight. Can the 6top layer
>> prevent the L2 Ack being sent? (And similar race conditions seem to be
>> possible in the 3-step transaction.)
>>
>> [Qin] Firstly, sincethe L2 Ack is sent by L2 according to IEEE802.15.4, 6top 
>> layer cannot preventit happen. Secondly, the race condition described above 
>> unlikely happens,because it is required that “The value of the 6P Timeout 
>> should be larger thanthe longest possible time it can take for the exchange 
>> to finish.” (3.4.4)
> 
> I'm sorry but that sounds like magic. Then whole point of race conditions is 
> that
> they happen in *very* unlikely cases such as the exchange taking 10 times 
> normal
> for some reason. If it only happens one time in ten million it is still a 
> problem.
> So I think you need to state what happens - maybe the inconsistency will be
> discovered later? That's fine for something considered highly unlikely.
> [Qin] Add following textin both section 3.1.1 and 3.1.2
> In case a race conditionhappens during the communication, the TSCH schedule 
> of node A may becomeinconsistent with the TSCH schedule of node B. 6top 
> handles the schedule inconsistency in the way described in Section3.4.6.2
>>
>>> 3.4.3.  Concurrent 6P Transactions
>>>
>>>   Only a single 6P Transaction between two neighbors, in a given
>>>   direction, can take place at the same time.  That is, a node MUST NOT
>>>   issue a new 6P Request to a given neighbor before having received the
>>>   6P Response for a previous request to that neighbor, except when the
>>>   previous 6P Transaction has timed out.  If a node receives a 6P
>>>   Request from a given neighbor before having sent the 6P Response to
>>>   the previous 6P Request from that neighbor, it MUST send back a 6P
>>>   Response with a return code of RC_RESET (as per Figure 36).  A node
>>>   receiving RC_RESET code MUST abort the transaction and consider it
>>>   never happened.
>>
>> It isn't clear to me whether the RC_RESET aborts the first, the second,
>> or both transactions.
>>
>> [Qin] change textto “abort the second transaction”
> 
> OK! 
>> Minor issues:
>> -
>>
>>> 1.  Introduction
>> ...
>>>   6P
>>>   allows a node to communicate with a neighbor to add/delete TSCH cells
>>>   to one another.
>>
>> This sentence is almost unintelligible because of the sequence to...to...to.
>> Does it mean this?:
>>
>>   6P allows neighbours to add or delete TSCH cells in each other.
>>
>> [Qin] Because we want to emphasize that communication between two nodes is 
>> the way to add/deletecells, we change text to “6P allows a node to 
>> communicate with a neighbor toadd/delete TSCH cells in each other”
>  
> 
> OK, that will be less confusing.
>  
>>> 3.4.1.  Version Checking
>>
>> This may be a pointless worry, but is there

Re: [Gen-art] [6tisch] Genart telechat review of draft-ietf-6tisch-6top-protocol-09

[Brian E Carpenter]

Hi Qin, see in line:

On 24/02/2018 04:16, Qin Wang wrote:
> Hi Brian,
> Thank you very much for your comments. Please see inline.
> 
> On Monday, February 19, 2018 6:22 PM, Brian Carpenter 
>  wrote: 
> 
>  Reviewer: Brian Carpenter
> Review result: Ready with Issues
> 
> Gen-ART Last Call review of draft-ietf-6tisch-6top-protocol-09
> 
> 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-6tisch-6top-protocol-09.txt
> Reviewer: Brian Carpenter
> Review Date: 2018-02-20
> IETF LC End Date: 2018-??-??
> IESG Telechat date: 2018-03-06
> 
> Summary: Ready with issues
> 
> 
> Comment:
> 
> 
> This is a Last Call review despite the subject field. When will the Last
> Call be started?
> 
> Major issues:
> -
> 
> In section 3.1.1 "2-step 6P Transaction" there seems to be a race condition
> if A's timeout expires while B's Response is in flight. Can the 6top layer
> prevent the L2 Ack being sent? (And similar race conditions seem to be
> possible in the 3-step transaction.)
> 
> [Qin] Firstly, sincethe L2 Ack is sent by L2 according to IEEE802.15.4, 6top 
> layer cannot preventit happen. Secondly, the race condition described above 
> unlikely happens,because it is required that “The value of the 6P Timeout 
> should be larger thanthe longest possible time it can take for the exchange 
> to finish.” (3.4.4)

I'm sorry but that sounds like magic. Then whole point of race conditions is 
that
they happen in *very* unlikely cases such as the exchange taking 10 times normal
for some reason. If it only happens one time in ten million it is still a 
problem.
So I think you need to state what happens - maybe the inconsistency will be
discovered later? That's fine for something considered highly unlikely.
> 
>> 3.4.3.  Concurrent 6P Transactions
>>
>>   Only a single 6P Transaction between two neighbors, in a given
>>   direction, can take place at the same time.  That is, a node MUST NOT
>>   issue a new 6P Request to a given neighbor before having received the
>>   6P Response for a previous request to that neighbor, except when the
>>   previous 6P Transaction has timed out.  If a node receives a 6P
>>   Request from a given neighbor before having sent the 6P Response to
>>   the previous 6P Request from that neighbor, it MUST send back a 6P
>>   Response with a return code of RC_RESET (as per Figure 36).  A node
>>   receiving RC_RESET code MUST abort the transaction and consider it
>>   never happened.
> 
> It isn't clear to me whether the RC_RESET aborts the first, the second,
> or both transactions.
> 
> [Qin] change textto “abort the second transaction”

OK! 
> Minor issues:
> -
> 
>> 1.  Introduction
> ...
>>   6P
>>   allows a node to communicate with a neighbor to add/delete TSCH cells
>>   to one another.
> 
> This sentence is almost unintelligible because of the sequence to...to...to.
> Does it mean this?:
> 
>   6P allows neighbours to add or delete TSCH cells in each other.
> 
> [Qin] Because we want to emphasize that communication between two nodes is 
> the way to add/deletecells, we change text to “6P allows a node to 
> communicate with a neighbor toadd/delete TSCH cells in each other”
 

OK, that will be less confusing.
 
>> 3.4.1.  Version Checking
> 
> This may be a pointless worry, but is there a DOS attack of some kind
> by sending rubbish version numbers?
> 
> [Qin] I think thatnot only the field of Version Number, but also other 
> fields, such as the fieldof Command Identifier can be filled with rubbish for 
> DOS attack. So, I wonderif it is necessary for Version Number field to be 
> treated differently. 
> 
> I would like asksecurity people to help on the question.

Maybe you need to mention in the Security Considerations that you have
no protection against a bad actor sending rubbish as a DOS. If all
nodes are authenticated when they join the network, this seems an
acceptable risk. 

Regards
 Brian
 
> ThanksQin
> ___
> 6tisch mailing list
> 6ti...@ietf.org
> https://www.ietf.org/mailman/listinfo/6tisch
> 
> 
>
> 

___
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-httpbis-origin-frame-04

[Brian E Carpenter]

Works for me.

Brian

On 28/11/2017 13:33, Mark Nottingham wrote:
> Thanks again. Please see:
>   https://github.com/httpwg/http-extensions/commit/871a80d12aa
> 
> 
>> On 27 Nov 2017, at 1:05 pm, Brian E Carpenter <brian.e.carpen...@gmail.com> 
>> wrote:
>>
>> Hi Mark,
>>
>> On 27/11/2017 12:38, Mark Nottingham wrote:
>>> Hi Brian,
>>>
>>> Thanks for the review. Responses below.
>>>
>>>> On 26 Nov 2017, at 2:44 pm, Brian Carpenter <brian.e.carpen...@gmail.com> 
>>>> wrote:
>>> [...]
>>>> Minor Issues:
>>>> -
>>>>
>>>>> 2.1.  Syntax
>>>> ...
>>>>> Origin: An OPTIONAL sequence of characters ... that the
>>>>> sender believes this connection is or could be authoritative for.
>>>>
>>>> So, that implies that all data in the ORIGIN frame might be false.
>>>> Doesn't that deserve a bit of a health warning at the beginning of the
>>>> Security Considerations?
>>>
>>> The first paragraph of SC is already:
>>>
>>> """
>>>   Clients that blindly trust the ORIGIN frame's contents will be
>>>   vulnerable to a large number of attacks.  See Section 2.4 for mitigations.
>>> """
>>>
>>> What would you suggest?
>>>
>>>> Also, using the word "believes" of a server
>>>> is strange. How would the server acquire uncertain knowledge in the
>>>> first place, and what algorithm would decide what it "believes"?
>>>
>>> This is to emphasise that ORIGIN is advisory only -- it does not constitute 
>>> proof (crypto does that).
>>
>> Right. But I think it's the anthropomorphic choice of word that triggered 
>> me. If you said "that the sender asserts this connection is or could be 
>> authoritative for" I think I'd have nothing further to say, since it's 
>> clearly an assertion that needs to be checked.
>>
>>>
>>>> Appendix A doesn't show any sign of a client checking whether an
>>>> Origin-Entry is real.
>>>
>>> As per Section 2.4, it isn't checked when the origin set is created or 
>>> updated; it's checked when the value is used.
>>
>> OK
>>
>>>
>>>
>>>>> 2.3.  The Origin Set
>>>> ...
>>>>> o  Host: the value sent in Server Name Indication (SNI, [RFC6066]
>>>>>Section 3), converted to lower case
>>>>
>>>> In that reference:
>>>>
>>>>>> Literal IPv4 and IPv6 addresses are not permitted in "HostName".
>>>>
>>>> Is that an intended or unintended restriction for the ORIGIN frame?
>>>> In any case it should probably be mentioned explicitly to avoid confusion.
>>>> (If IPv6 literals were allowed, they might be very convenient for server
>>>> load balancing. But RFC6066 excludes that.)
>>>
>>> Good catch. I don't think there's cause for confusion here (the text there 
>>> isn't about what can go on the wire), but there is a corner case we haven't 
>>> covered (when a client that supports SNI omits it because it's an IP 
>>> literal). 
>>>
>>> My inclination there is to say that the host is the SNI value or the server 
>>> IP if SNI is missing; what do people think?
>>
>>> From this reviewer's peanut gallery seat, that makes sense.
>>
>>   Brian
>>
>>>
>>> Cheers,
>>>
>>> --
>>> Mark Nottingham   https://www.mnot.net/
>>>
>>>
> 
> --
> Mark Nottingham   https://www.mnot.net/
> 
> 

___
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-httpbis-origin-frame-04

[Brian E Carpenter]

Hi Mark,

On 27/11/2017 12:38, Mark Nottingham wrote:
> Hi Brian,
> 
> Thanks for the review. Responses below.
> 
>> On 26 Nov 2017, at 2:44 pm, Brian Carpenter  
>> wrote:
> [...]
>> Minor Issues:
>> -
>>
>>> 2.1.  Syntax
>> ...
>>> Origin: An OPTIONAL sequence of characters ... that the
>>> sender believes this connection is or could be authoritative for.
>>
>> So, that implies that all data in the ORIGIN frame might be false.
>> Doesn't that deserve a bit of a health warning at the beginning of the
>> Security Considerations?
> 
> The first paragraph of SC is already:
> 
> """
>Clients that blindly trust the ORIGIN frame's contents will be
>vulnerable to a large number of attacks.  See Section 2.4 for mitigations.
> """
> 
> What would you suggest?
> 
>> Also, using the word "believes" of a server
>> is strange. How would the server acquire uncertain knowledge in the
>> first place, and what algorithm would decide what it "believes"?
> 
> This is to emphasise that ORIGIN is advisory only -- it does not constitute 
> proof (crypto does that).

Right. But I think it's the anthropomorphic choice of word that triggered me. 
If you said "that the sender asserts this connection is or could be 
authoritative for" I think I'd have nothing further to say, since it's clearly 
an assertion that needs to be checked.
 
> 
>> Appendix A doesn't show any sign of a client checking whether an
>> Origin-Entry is real.
> 
> As per Section 2.4, it isn't checked when the origin set is created or 
> updated; it's checked when the value is used.

OK

> 
> 
>>> 2.3.  The Origin Set
>> ...
>>>  o  Host: the value sent in Server Name Indication (SNI, [RFC6066]
>>> Section 3), converted to lower case
>>
>> In that reference:
>>
 Literal IPv4 and IPv6 addresses are not permitted in "HostName".
>>
>> Is that an intended or unintended restriction for the ORIGIN frame?
>> In any case it should probably be mentioned explicitly to avoid confusion.
>> (If IPv6 literals were allowed, they might be very convenient for server
>> load balancing. But RFC6066 excludes that.)
> 
> Good catch. I don't think there's cause for confusion here (the text there 
> isn't about what can go on the wire), but there is a corner case we haven't 
> covered (when a client that supports SNI omits it because it's an IP 
> literal). 
> 
> My inclination there is to say that the host is the SNI value or the server 
> IP if SNI is missing; what do people think?

>From this reviewer's peanut gallery seat, that makes sense.

   Brian

> 
> Cheers,
> 
> --
> Mark Nottingham   https://www.mnot.net/
> 
> 

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

Re: [Gen-art] Genart telechat review of draft-ietf-lime-yang-connectionless-oam-methods-09

[Brian E Carpenter]

A small response in line below:

On 26/10/2017 04:16, Alissa Cooper wrote:
> Brian, thank you for your review. Qin, thanks for your responses. I have 
> entered a No Objection ballot that captures the remaining open issue 
> concerning one-way vs. two-way delay. One further comment below.
> 
>> On Oct 18, 2017, at 9:09 PM, Qin Wu <bill...@huawei.com> wrote:
>>
>> -邮件原件-
>> 发件人: Brian E Carpenter [mailto:brian.e.carpen...@gmail.com] 
>> 发送时间: 2017年10月19日 3:26
>> 收件人: Qin Wu; gen-art@ietf.org
>> 抄送: draft-ietf-lime-yang-connectionless-oam-methods@ietf.org; 
>> l...@ietf.org
>> 主题: Re: Genart telechat review of 
>> draft-ietf-lime-yang-connectionless-oam-methods-09
>>
>> On 17/10/2017 14:40, Qin Wu wrote:
>> ...
>>
>>>> The same is applied to jitter. As clarified in the introduction, the 
>>>> definition of 'jitter' is used to monitor reachability of destinations, 
>>>> troubleshoot failures, monitor performance.
>>>
>>> Yes, but what *is* jitter physically? There is no scientific definition of 
>>> 'jitter' in the IETF. Do you mean IPDV as defined in RFC3393 or something 
>>> else?
>>>
>>> [Qin]:Jitter is packet jitter (https://en.wikipedia.org/wiki/Jitter). 
>>> You are right, one typical example of packet jitter is IPDV defined in 
>>> RFC3393, but we don't want to limit it to IPDV, we also allow support other 
>>> protocol and other measurement methodology, e.g., we could also consider to 
>>> use MAPDV2 defined in [ITU-T G.1020], what protocol is used and what 
>>> methodology is used can be indicated by the parameter 'protocol-id' 
>>> parameter and 'protocol-id-meta-data' in this model.
>>
>> I don't see how this specification can be used for interoperable 
>> implementations unless you define a specific meaning of 'jitter'.
>>
>> If the network management system assumes RFC3393 but half the routers in the 
>> network implement G.1020, there is no interoperability.
> 
> I believe this is well-specified in draft-ietf-lime-yang-connectionless-oam:

Yes. Maybe it would help to mention in the Introduction of 
ietf-lime-yang-connectionless-oam-methods that some elements of the data model 
are fully defined in ietf-lime-yang-connectionless-oam. The current text says 
"It is separated from the generic YANG model for connectionless OAM" but does 
not tell the reader to go and read the generic model!

Brian

> 
> grouping session-jitter-statistics {
> description
>   "Grouping for per session jitter statistics";
> container session-jitter-statistics {
>   description
> "Session jitter summarised information. By default,
>  jitter is measured using IP Packet Delay Variation
>  (IPDV) as defined in RFC3393 <https://tools.ietf.org/html/rfc3393>. 
> When the other measurement
>  method is used instead(e.g., Packet Delay Variation used in
>  Y.1540, it can be indicated using protocol-id-meta-data
>  defined in RPC operation of
>  draft-ietf-lime-yang-connectionless-oam-methods 
> <https://tools.ietf.org/html/draft-ietf-lime-yang-connectionless-oam-methods>.
>  Note that
>  only one measurement method for jitter is specified
>  for interoperability reason.";
> 
> Alissa
> 
>>
>> [Qin]: Correct, Just to clarify, it is not our intent to encourage 
>> implementer to support various different mechanisms to measure jitter in one 
>> single solution.
>> In one single solution, we will restrict to use one mechanism, one protocol 
>> to measure jitter, but flexibility we allow here, you might choose different 
>> time units,
>> But again we might only allow one time unit in one single solution, 
>> introduce protocol-id parameter is used to allow future protocol and future 
>> mechanism to be created then we support different mechanism to measure 
>> Jitter with different time unit.
>>
>>> I assume that by 'delay' you mean RFC7679 rather than RFC2681, but that 
>>> seems straightforward,  and so do the other metrics used in 
>>> session-packet-statistics and session-error-statistics.
>>>
>>> [Qin]: Correct, it is one way delay instead of two way delay. 
>>
>> Again - it is useful to specify one-way delay, for interoperability.
>> (Whether the routers can measure one-way delay is another question; they 
>> might be forced to measure RTT and assume delay = RTT/2 .)
>>
>> [Qin]: Agree, have a second thought, I think with protocol-id, we 

Re: [Gen-art] I-D Action: draft-ietf-lime-yang-connectionless-oam-methods-10.txt

[Brian E Carpenter]

Hi,

I don't see all the changes that were discussed in this version, and the typo in
'propreitary' has not been fixed. This does not seem ready for the telechat to 
me.

Regards
   Brian

On 24/10/2017 02:00, internet-dra...@ietf.org wrote:
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Layer Independent OAM Management in the 
> Multi-Layer Environment WG of the IETF.
> 
> Title   : Retrieval Methods YANG Data Model for 
> Connectionless Operations, Administration, and Maintenance(OAM) protocols
> Authors : Deepak Kumar
>   Michael Wang
>   Qin Wu
>   Reshad Rahman
>   Srihari Raghavan
>   Filename: draft-ietf-lime-yang-connectionless-oam-methods-10.txt
>   Pages   : 35
>   Date: 2017-10-23
> 
> Abstract:
>This document presents a retrieval method YANG Data model for
>connectionless OAM protocols.  It provides technology-independent RPC
>operations for connectionless OAM protocols.  The retrieval methods
>model presented here can be extended to include technology specific
>details.  This is leading to uniformity between OAM protocols and
>support both nested OAM workflows (i.e., performing OAM functions at
>different levels through a unified interface) and interacting OAM
>workflows ( i.e., performing OAM functions at same levels through a
>unified interface).
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-lime-yang-connectionless-oam-methods/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-lime-yang-connectionless-oam-methods-10
> https://datatracker.ietf.org/doc/html/draft-ietf-lime-yang-connectionless-oam-methods-10
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-lime-yang-connectionless-oam-methods-10
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> ___
> I-D-Announce mailing list
> i-d-annou...@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 

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

Re: [Gen-art] Genart telechat review of draft-ietf-lime-yang-connectionless-oam-methods-09

[Brian E Carpenter]

On 17/10/2017 14:40, Qin Wu wrote:
...

>> The same is applied to jitter. As clarified in the introduction, the 
>> definition of 'jitter' is used to monitor reachability of destinations, 
>> troubleshoot failures, monitor performance.
> 
> Yes, but what *is* jitter physically? There is no scientific definition of 
> 'jitter' in the IETF. Do you mean IPDV as defined in RFC3393 or something 
> else?
> 
> [Qin]:Jitter is packet jitter (https://en.wikipedia.org/wiki/Jitter). You are 
> right, one typical example of packet jitter is IPDV defined in RFC3393, but 
> we don't want to limit it to IPDV, we also allow support other protocol and 
> other measurement methodology,
> e.g., we could also consider to use MAPDV2 defined in [ITU-T G.1020], what 
> protocol is used and what methodology is used can be indicated by the 
> parameter 'protocol-id' parameter and 'protocol-id-meta-data' in this model.

I don't see how this specification can be used for interoperable
implementations unless you define a specific meaning of 'jitter'.
If the network management system assumes RFC3393 but half the
routers in the network implement G.1020, there is no interoperability.

> I assume that by 'delay' you mean RFC7679 rather than RFC2681, but that seems 
> straightforward,  and so do the other metrics used in 
> session-packet-statistics and session-error-statistics.
> 
> [Qin]: Correct, it is one way delay instead of two way delay. 

Again - it is useful to specify one-way delay, for interoperability.
(Whether the routers can measure one-way delay is another question;
they might be forced to measure RTT and assume delay = RTT/2 .)

Regards
Brian

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

Re: [Gen-art] Genart telechat review of draft-ietf-lime-yang-connectionless-oam-methods-09

[Brian E Carpenter]

Qin,

Thanks for the reply, I have follow-up questions in line:

On 17/10/2017 00:52, Qin Wu wrote:
> Thank Brian for valuable review to this document, please see my reply below.
> 
> -Qin
> -邮件原件-
> 发件人: Brian Carpenter [mailto:brian.e.carpen...@gmail.com] 
> 发送时间: 2017年10月14日 12:40
> 收件人: gen-art@ietf.org
> 抄送: draft-ietf-lime-yang-connectionless-oam-methods@ietf.org; 
> l...@ietf.org
> 主题: Genart telechat review of 
> draft-ietf-lime-yang-connectionless-oam-methods-09
> 
> Reviewer: Brian Carpenter
> Review result: Ready with Issues
> 
> Gen-ART *Last Call* review of 
> draft-ietf-lime-yang-connectionless-oam-methods-09
> 
> 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-lime-yang-connectionless-oam-methods-09.txt
> Reviewer: Brian Carpenter
> Review Date: 2017-10-14
> IETF LC End Date: 2017-10-25
> IESG Telechat date: 2017-10-26
> 
> Summary: Ready with issues
> 
> 
> Comment:
> 
> 
> The shepherd says:
> 
>> This includes at least two different implementations of the model, as 
>> well as product and demos at Bits-n-Bytes.
> 
> Shouldn't WGs make routine use of BCP 205, RFC 7942 "Improving Awareness of 
> Running Code: The Implementation Status Section"?
> 
> Minor Issues:
> -
> 
> In the following:
> 
>  |  +--ro min-delay-value? uint32
>  |  +--ro max-delay-value? uint32
>  |  +--ro average-delay-value? uint32
>  +--ro session-jitter-statistics
>  |  +--ro time-resolution-value?   identityref
>  |  +--ro min-jitter-value?uint32
>  |  +--ro max-jitter-value?uint32
>  |  +--ro average-jitter-value?uint32
> 
> what are the units for the delay-value and jitter-value elements, and what 
> definition of 'jitter' is intended?
> 
> [Qin]: Delay supports various time units such as s,ms,ns and etc.
> To represent this using YANG construct, we introduce a new parameter 
> time-resolution-value as follows:
>| +--ro session-delay-statistics
>| |  +--ro time-resolution-value?   identityref
>| |  +--ro min-delay-value? uint32
>| |  +--ro max-delay-value? uint32
>| |  +--ro average-delay-value? uint32
> With this time-resolution-value parameter, we can support various different 
> time unit.

OK, because of my poor understanding of YANG, I still have to ask where
the possible values of time-resolution-value are defined. Is there
an enumeration somewhere that I have missed?

> The same is applied to jitter. As clarified in the introduction, the 
> definition of 'jitter' is used to 
> monitor reachability of destinations, troubleshoot failures, monitor 
> performance.

Yes, but what *is* jitter physically? There is no scientific definition of
'jitter' in the IETF. Do you mean IPDV as defined in RFC3393 or something
else?

I assume that by 'delay' you mean RFC7679 rather than RFC2681, but that seems
straightforward,  and so do the other metrics used in session-packet-statistics
and session-error-statistics.

Regards
Brian

> 
>   identity protocol-id-internet {
> base protocol-id;
> description
>   "Internet Protocols.";
>   }
> 
> It isn't clear what "Internet Protocols" means. It seems totally non-specific.
> 
> 
> [Qin]: It is referred to a standard protocol (e.g., TCP/IP protocols, ICMP, 
> IGMP,etc.,)
> We can make this clear by adding a few clarification text in the description 
> of protocol-id-internet.
> Nits:
> -
> 
>   identity protocol-id-propreitary {
> base protocol-id;
> description
>   "Propreitary protocol (eg.,IP SLA).";
> 
> s/propreitary/proprietary/
> s/Propreitary/Proprietary/
> 
> [Qin]: Thanks and will get this fixed.
> 

___
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-anima-prefix-management-05

[Brian E Carpenter]

Thanks Dan. Good comments, and I think we can deal with them
all quite easily when the Last Call expires.

Regards
   Brian

On 05/10/2017 20:40, Dan Romascanu wrote:
> Reviewer: Dan Romascanu
> Review result: Ready with Issues
> 
> 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-prefix-management-??
> Reviewer: Dan Romascanu
> Review Date: 2017-10-04
> IETF LC End Date: 2017-10-12
> IESG Telechat date: Not scheduled for a telechat
> 
> Summary:
> 
> This document describes an ANIMA solution for IPv6 prefix management at the
> edge of large-scale ISP networks sketches an IPv4 solution extension to 
> support
> IPv4 prefixes. It is well written, targeting the operators of ISP networks,
> describes the solution in a manner very clear for people familiar with the ANI
> framework, with useful deployment examples. There are a few minor issues that 
> I
> recommend to clarify.
> 
> Major issues:
> 
> Minor issues:
> 
> 1. In Section 3:
> 
> ' Roles could be
>locally defined or could be generic (edge router, interior router,
>etc.).'
> 
> I am a little confused by the locally defined roles concept. Do the brackets
> refer only to the generic roles? If so, what would be the examples of locally
> defined roles?
> 
> 2. Section 3.2.1 - what does 'Identity of this device' mean in this context? A
> clarification may be needed.
> 
> 3. Section 4. The presence of a PrefixManager ASA seems to be a fundamental
> requirement for the solution described in the document. Consider using a
> capitalized MUST to emphasize this.
> 
> 4. Section 4.1:
> 
> ' It
>should decide the length of the requested prefix and request it by
>the mechanism described in Section 6.'
> 
> Is not the length of the requested prefix a function of the device role? What
> is left to the device to decide?
> 
> 5.  Section 7. Related to my previous lack of clarity about device identity
> being decided by the device. Is this not a potential threat? It does not seem
> to be taken into consideration in the referred security documents.
> 
> 6. [I-D.ietf-cbor-cddl] and [I-D.ietf-core-yang-cbor] seem to be required
> reading in case the respective options are being used. Consider moving these 
> as
> Normative References.
> 
> Nits/editorial comments:
> 
> 1. Section 1:
> 
> '  A generic autonomic signaling protocol
>(GRASP) is specified by [I-D.ietf-anima-grasp] and would be used by
>the proposed autonomic prefix management solution. '
> 
> I am confused by the use of 'would'. Does it mean that GRASP is just an
> example? Are there other to be taken into consideration? If using this 
> document
> to validate the design of GRASP is the principal scope, why the conditional
> mode?
> 
> 2. need to expand acronyms at first occurrence - e.g. DHCPv6-PD, CBOR, etc.
> 
> 3. I am not sure what 'Abstract' means in the name of the Appendix section
> 'Abstract Deployment Overview'
> 
> 
> 

___
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-grow-bgp-session-culling-04

[Brian E Carpenter]

Hi Matt,
On 22/09/2017 07:08, Matt Griswold wrote:
> * Brian E Carpenter <brian.e.carpen...@gmail.com> [170921 14:19 +1200]:
>> On 21/09/2017 12:13, Matt Griswold wrote:
>>> * Brian Carpenter <brian.e.carpen...@gmail.com> [170918 21:44
>>>   -0700]:  
>>>> Minor Issues:
>>>> -
>>>>  
>>>>> 3.1.1.  Maintenance Considerations
>>>>>
>>>>>  Initiators of the administrative shutdown could consider using
>>>>>  Graceful Shutdown [I-D.ietf-grow-bgp-gshut] to facilitate smooth
>>>>>  drainage of traffic prior to session tear down, and the Shutdown
>>>>>  Communication [I-D.ietf-idr-shutdown]...
>>>>
>>>> This strikes me as vague. "Could consider"? Surely if this is
>>>> a BCP, they MUST use some mechanisms and perhaps SHOULD use these
>>>> particular mechanisms. Otherwise the document doesn't specify
>>>> anything much at all for this case.  
>>>
>>> Graceful Shutdown is just one of multiple ways an Operator can
>>> accomplish that.  
>>
>> Understood, so perhaps it's a MAY not a SHOULD
> 
> You're right, I will update it to MAY.
> 
>> but the text still really only seems to say "do the right thing"
>> without saying what that is. To be honest the whole document is a bit
>> like that - written for members of the club who know how to run BGP,
>> rather than for a newcomer who wants to know how to run BGP.
> 
> That's really by design, the document is for people who know and run
> BGP, I think putting too much basic BGP knowledge would make it
> monotonous. Any ideas on how to meet in the middle?

Your suggestion below "Adding a brief scenario paragraph should work,
I'll write something up." would do it, I think. (I should add that my
perspective is that of someone who understands in theory how BGP is supposed
to work but has never personally practiced it - I'm not suggesting you
need to cover everything, just supply a few clues.)

> 
>>>> Secondly, if there are no fault indications, what causes the
>>>> Caretaker to cull sessions? What's the trigger? Is the Caretaker
>>>> supposed to know by magic that layer 2 maintenance is planned?  
>>>
>>> The Caretaker controls the layer 2 network, so yes, would do this as
>>> part of the maintenance process.  
>>
>> Again: not clear to a newcomer.
> 
> The updated language is:
> 
>   Throughout this document the "Caretaker" is defined to be in control
>   of the lower layer network, while "Operators" directly administrate
>   the BGP speakers.
> 
> I think that clears it up?

Yes.

> 
>>>> And in Appendix A, explain precisely how the example prefixes are
>>>> used: what makes them relevant? Are they normally announced by BGP
>>>>   to all the IXP's BGP peers?  
>>>
>>> They are the IXP LAN addresses, as explained above the examples.  
>>
>> Yes, I realise that, but again you're assuming that the reader has
>> a complete picture in her mind. Maybe there's actually a need for
>> a scenario description in the Introduction, or at least a reminder
>> that in normal operation, paths through the fabric in question may be
>> known throughout the BGP realm, and the objective is to delete
>> those paths before starting maintenance.
> 
> Again, that section is for IXP Caretakers so I don't think we need to
> go into IXP operational details too much. Adding a brief scenario
> paragraph should work, I'll write something up.

Great.

Brian

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

Re: [Gen-art] Genart telechat review of draft-ietf-tsvwg-ecn-experimentation-05

[Brian E Carpenter]

Thanks David. That completely responds to my comments.

Regards
   Brian

On 21/09/2017 10:45, Black, David wrote:
> Brian,
> 
> I'm about to post the -06 version of this draft.   The concern on RFC 3168 
> impact of the ECN nonce removal was resolved by listing the four major 
> changes (and you were correct that the change to Section 20.2 is subtle - I 
> got it wrong on my first attempt in responding to your email).  Here's the 
> specific text that I've added to Section 3 of the draft:
> 
>The four primary updates to RFC 3168 that remove discussion of the
>ECN nonce and use of ECT(1) for that nonce are:
> 
>1.  Remove the paragraph in Section 5 that immediately follows
>Figure 1; this paragraph discusses the ECN nonce as the
>motivation for two ECT codepoints.
> 
>2.  Remove Section 11.2 "A Discussion of the ECN nonce." in its
>entirety.
> 
>3.  Remove the last paragraph of Section 12, which states that ECT(1)
>may be used as part of the implementation of the ECN nonce.
> 
>4.  Remove the first two paragraphs of Section 20.2, which discuss
>the ECN nonce and alternatives.  No changes are made to the rest
>of Section 20.2, which discusses alternate uses for the fourth
>ECN codepoint.
> 
>Additional minor changes remove other mentions of the ECN nonce and
>implications that ECT(1) is intended for use by the ECN nonce; the
>specific text updates are omitted for brevity.
> 
> The proverbial "rest of the story" is that an RFC 3168bis effort appears to 
> be a good idea, e.g., as RFC 6040 has already made some visible changes. The 
> preferred 3168bis timing appears to be after we understand the outcomes of 
> the current proposed of experiments, as they're likely to result in another 
> round of changes to RFC 3168.
> 
> Many thanks, and chalk this up as one more instance where a GenART review has 
> visibly improved the quality of a draft,  --David
> 
>> -Original Message-
>> From: Brian E Carpenter [mailto:brian.e.carpen...@gmail.com]
>> Sent: Friday, September 1, 2017 7:41 PM
>> To: Black, David <david.bl...@emc.com>; gen-art@ietf.org
>> Cc: draft-ietf-tsvwg-ecn-experimentation@ietf.org; ts...@ietf.org
>> Subject: Re: Genart telechat review of draft-ietf-tsvwg-ecn-
>> experimentation-05
>>
>> On 02/09/2017 09:45, Black, David wrote:
>>> Brian,
>>>
>>> Thanks for the prompt review.
>>>
>>>> Comment: Very clear from the technical standpoint.
>>>
>>> Thank you!
>>>
>>>> I understand the desire for brevity, but this bothers me a bit. What is
>>>> the reader to make of RFC3168 Section 20.2, for example? My feeling is
>>>> that a short Appendix outlining the specific updates would be useful.
>>>> There's already too much spaghetti to untangle.
>>>
>>> RFC 3168 Section 20.2 is the rationale for the ECN Nonce and hence would
>> be
>>> deleted. Request noted, I'll consult with the draft shepherd and
>> responsible
>>> AD to figure out whether to do this.
>>
>> Thanks. It's not intended as a blocking issue.
>>
>>>
>>>> I see no reason why RFC3540 and RFC5622 need to be normative
>> references
>>>> (and therefore downrefs). They aren't required reading in order to
>>>> understand this draft.
>>>
>>> OTOH, both are affected by this draft:
>>>
>>> In reverse order, this draft updates RFC 5622 - that seems to merit a
>>> normative reference.This draft also provides the rationale for the
>>> status change of RFC 3540 to Historic, which also seems to merit a
>>> normative reference.
>>
>> Well, my understanding is that a normative reference is needed only
>> when the citing document cannot be understood and implemented
>> without reading the cited document.
>>
>> Again it's not a blocking comment - although there is a technical error
>> in the Last Call message: it flags the downref to 5622, but not that to 3540.
>> I don't know if that's a tool error or an AD error ;-).
>>
>> Brian
>>
>>>
>>> Thanks, --David
>>>
>>>
>>>> -Original Message-
>>>> From: Brian Carpenter [mailto:brian.e.carpen...@gmail.com]
>>>> Sent: Thursday, August 31, 2017 10:02 PM
>>>> To: gen-art@ietf.org
>>>> Cc: draft-ietf-tsvwg-ecn-experimentation@ietf.org; ts...@ietf.org
>>>> Subject: Genart telechat review of draft-ietf-tsvwg-ecn-experimentation-
>> 05
>

Re: [Gen-art] draft-baeuerle-netnews-cancel-lock-06 and RFCs 5536 & 5322

[Brian E Carpenter]

> The question is: in the meantime, what to do about this draft? By 
> default I guess I will simply restate the issue in my genart telechat 
> review and leave it for the IESG discuss it.

That's about all you can do. Of course if the IESG approves it anyway
you can appeal that decision. I'm not aware of any case where a Gen-ART
reviewer has needed to do that, but there's a first time for everything,
and the plenaries are boring if there are no appeals to rehash ;-)

Regards
   Brian

On 19/09/2017 09:14, Paul Kyzivat wrote:
> I'm on tap to do the genart telechat review on 
> draft-baeuerle-netnews-cancel-lock-06. I see that nothing has been done 
> about the ABNF that was my primary concern in my prior wglc review of -05:
> 
> https://mailarchive.ietf.org/arch/msg/gen-art/wXKa5tadbo_xQbbUUCk9RZyB0w8
> 
> I'm told by the authors that Alexey asked that it be submitted this way, 
> but the ABNF *is* wrong, and I can't see how a new draft can be allowed 
> to be published with knowingly wrong ABNF. OTOH, the problem didn't 
> originate with this draft. Rather the problem originated with RFC5536, 
> and this draft has simply built on that mistake. Unfortunately the root 
> of the problem is with RFC5322, since its ABNF is structured in a way 
> that makes it really hard to define extensions such as those in RFC5536 
> and this draft. So the cleanest solution I can see is to revise both 
> 5322 and 5536, and then this draft can build on those changes. That is a 
> rather involved fix but I don't see any other reasonable way.
> 
> This prompted me to submit an erratum (#5116) on RFC5536 regarding this 
> issue. But errata aren't often acted on quickly when they require 
> revising RFCs.
> 
> The question is: in the meantime, what to do about this draft? By 
> default I guess I will simply restate the issue in my genart telechat 
> review and leave it for the IESG discuss it.
> 
> Anybody have a better idea?
> 
>   Thanks,
>   Paul
> 
> On 7/14/17 12:58 PM, Paul Kyzivat wrote:
>> Michael,
>>
>> Please see further comments inline.
>>
>> (Sorry - the indenting is getting deep, but I think we are pretty much 
>> done.)
>>
>> On 7/11/17 2:39 PM, Michael Bäuerle wrote:
>>> Paul Kyzivat wrote:
 On 7/7/17 11:47 AM, Michael Bäuerle wrote:
> Paul Kyzivat wrote:
>>
>> [...]
>> General Comments:
>>
>> I have not attempted to validate the security properties of this
>> document - leaving that to a security review.
>>
>> I have also not attempted to verify the operational suitability of 
>> this
>> mechanism because I don't have the experience needed to do so.
>>
>> Issues:
>>
>> Major: 1
>> Minor: 3
>> Nits:  0
>>
>> (1) MAJOR:
>>
>> [Problem with ABNF syntax of header fields]
>
> Hi Paul,
>
> Julien Élie has proposed a new syntax definition.

 I was copied on his mail proposing a change to RFC5536, and that is
 tentative. *This* document would of course require a similar change. Or
 else it could extend that change, via something like

 news-fields =/ cancel-lock / cancel-key

 But that can only be done if there is actually a draft that revises 5536
 that can then be referenced. Bottom line is that it seems there needs to
 be some coordination of that fix with this draft.
>>>
>>> It's clear that the Cancel-Lock draft needs to be changed. My comment
>>> was about the potential erratum for RFC 5536 and the question:
>>> Is it (in general) possible to reference a modified ABNF definition in
>>> an erratum?
>>
>> I don't know of any way to do so. Perhaps somebody else can provide a 
>> more definitive answer. You might try asking on rfc-interest.
>>
>>> If this is possible, then the current:
>>>
>>>     fields =/ *( cancel-lock / cancel-key )
>>>
>>> can be changed to:
>>>
>>>     news-fields =/ cancel-lock / cancel-key
>>>
>>> and should then reference the new ABNF from the erratum.
>>> If not, what about a less formal definition like this:
>>>
>>>     The Cancel-Lock and Cancel-Key header fields MUST be treated as
>>>     though it were news header fields as defined in Section 3 of
>>>     [RFC5536].
>>
>> I'm not sure about that. It might fly, or not. Again, I think you need 
>> to ask somebody more authoritative.
>>
>>> Rewriting RFC 5322 and RFC 5536 should be avoided if possible.
>>
>> I understand why you might not want to take on responsibility for that. 
>> But it is the right thing to do. Question is whether it needs to be done 
>> now.
>>
>> (2) Minor:
>>
>> In Section 3.5, step 1 says to hash the key using the algorithm 
>> from its
>> scheme. But IIUC the scheme describes the algorithm that has already
>> been used when constructing the Cancel-Key header.
>
> No. There are two different operations that use a hash function.
>
> The recommended algorithm described in Section 4 calculates:
> |
> | K = HMAC(uid+mid, 

Re: [Gen-art] Genart telechat review of draft-ietf-tsvwg-ecn-experimentation-05

[Brian E Carpenter]

On 02/09/2017 09:45, Black, David wrote:
> Brian,
> 
> Thanks for the prompt review.
> 
>> Comment: Very clear from the technical standpoint. 
> 
> Thank you!
> 
>> I understand the desire for brevity, but this bothers me a bit. What is
>> the reader to make of RFC3168 Section 20.2, for example? My feeling is
>> that a short Appendix outlining the specific updates would be useful.
>> There's already too much spaghetti to untangle.
> 
> RFC 3168 Section 20.2 is the rationale for the ECN Nonce and hence would be
> deleted. Request noted, I'll consult with the draft shepherd and responsible
> AD to figure out whether to do this.

Thanks. It's not intended as a blocking issue.

> 
>> I see no reason why RFC3540 and RFC5622 need to be normative references
>> (and therefore downrefs). They aren't required reading in order to
>> understand this draft.
> 
> OTOH, both are affected by this draft:
> 
> In reverse order, this draft updates RFC 5622 - that seems to merit a
> normative reference.This draft also provides the rationale for the
> status change of RFC 3540 to Historic, which also seems to merit a
> normative reference.

Well, my understanding is that a normative reference is needed only
when the citing document cannot be understood and implemented
without reading the cited document.

Again it's not a blocking comment - although there is a technical error
in the Last Call message: it flags the downref to 5622, but not that to 3540.
I don't know if that's a tool error or an AD error ;-).

Brian

> 
> Thanks, --David
> 
> 
>> -Original Message-
>> From: Brian Carpenter [mailto:brian.e.carpen...@gmail.com]
>> Sent: Thursday, August 31, 2017 10:02 PM
>> To: gen-art@ietf.org
>> Cc: draft-ietf-tsvwg-ecn-experimentation@ietf.org; ts...@ietf.org
>> Subject: Genart telechat review of draft-ietf-tsvwg-ecn-experimentation-05
>>
>> Reviewer: Brian Carpenter
>> Review result: Ready with Issues
>>
>> Gen-ART Last Call review of draft-ietf-tsvwg-ecn-experimentation-05
>>
>> 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-tsvwg-ecn-experimentation-05.txt
>> Reviewer: Brian Carpenter
>> Review Date: 2017-09-01
>> IETF LC End Date: 2017-09-14
>> IESG Telechat date: 2017-09-14
>>
>> Summary: Ready with (minor) issues
>> 
>>
>> Comment: Very clear from the technical standpoint.
>> 
>>
>> Minor Issues:
>> -
>>
>>> 3.  ECN Nonce and RFC 3540
>> ...
>>> o  Updates RFC 3168 [RFC3168] to remove discussion of the ECN Nonce
>>>and use of ECT(1) for that Nonce.  The specific text updates are
>>>omitted for brevity.
>>
>> I understand the desire for brevity, but this bothers me a bit. What is
>> the reader to make of RFC3168 Section 20.2, for example? My feeling is
>> that a short Appendix outlining the specific updates would be useful.
>> There's already too much spaghetti to untangle.
>>
>> I see no reason why RFC3540 and RFC5622 need to be normative references
>> (and therefore downrefs). They aren't required reading in order to
>> understand this draft.
>>
>> --
> 

___
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-trill-mtu-negotiation-05

[Brian E Carpenter]

Thanks, all those changes seem good to me. If I am asked to review
the next version for the IESG telechat, I expect to say "Ready".

Regards
   Brian

On 27/06/2017 20:06, Zhangmingui (Martin) wrote:
> Hi Brian and Donald,
> 
> Thanks a lot for the comments. Please see the responses as inline below.
> 
>> -Original Message-
>> From: Donald Eastlake [mailto:d3e...@gmail.com]
>> Sent: Tuesday, June 27, 2017 11:03 AM
>> To: Brian Carpenter
>> Cc: gen-art@ietf.org Review Team; 
>> draft-ietf-trill-mtu-negotiation@ietf.org;
>> tr...@ietf.org
>> Subject: Re: Genart last call review of draft-ietf-trill-mtu-negotiation-05
>>
>> Hi Brian,
>>
>> Thanks for the comments. See below.
>>
>> On Fri, Jun 23, 2017 at 9:32 PM, Brian Carpenter
>>  wrote:
>>> Reviewer: Brian Carpenter
>>> Review result: Ready with Issues
>>>
>>> Gen-ART Last Call review of draft-ietf-trill-mtu-negotiation-05
>>>
>>> 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-trill-mtu-negotiation-05.txt
>>> Reviewer: Brian Carpenter
>>> Review Date: 2017-06-24
>>> IETF LC End Date: 2017-06-28
>>> IESG Telechat date: 2017-07-06
>>>
>>> Summary: Ready with issues
>>> 
>>>
>>> Minor issues:
>>> -
>>>
 2. Link-Wide TRILL MTU Size
>>> ...
   ...RBridges MUST support the Extended L1 Circuit-Scoped
   (E-L1CS) flooding scope LSP (FS-LSP). They use that flooding to
   exchange their maximally supportable value of "Lz".
>>>
>>> Where does that value come from? Is it configured, derived from the
>>> interface in some way, or discovered?
>>
>> It's somewhat similar to the originatingL1LSPBufferSize which is talked 
>> about in
>> Section 5 of RFC 7780, except that there is no reason to worry about
>> coordinating across the TRILL campus. How about adding wording something
>> like:
>>
>>   The originatingSNPBufferSize for a port is the minimum of the following
>> two quantities, but not less than 1470 bytes: (1) the maximum MTU of the port
>> and (2) the maximum LSP size that the TRILL IS-IS implementation can handle,
> 
> [Mingui] OK.
> 
>>
 2.1. Operations

   Lz is reported using a originatingSNPBufferSize TLV that MUST occur
   in fragment zero of the RBridge's E-L1CS FS-LSP. An
   originatingSNPBufferSize APPsub-TLV occurring in any other fragment
   is ignored.
>>>
>>> Is that really what you mean? I thought Lz was an optional extra. So I
>>> think you mean:
>>>
>>> 2.1. Operations
>>>
>>>Lz MAY be reported using a originatingSNPBufferSize TLV that occurs
>>>in fragment zero of the RBridge's E-L1CS FS-LSP. An
>>>originatingSNPBufferSize APPsub-TLV occurring in any other fragment
>>>MUST be ignored.
> 
> [Mingui] OK.
> 
>>
>> Yes, the "MUST" was just in reference to being in fragment zero, not that it 
>> has
>> to occur, so your wording seems better.
>>
 3. Link MTU Size Testing
>>> ...
   Step 0:
>>> ...
  b) Link MTU size is set to 1470, lowerBound is set to 1470,
 upperBound is set to the link-wide Lz, linkMtuSize is set to
 [(lowerBound + upperBound)/2] (Operation "[...]" returns the
 fraction-rounded-up integer.).
>>>
>>> This is confusing. "linkMtuSize" was defined as a local variable.
>>> But what is "Link MTU size"? Is that another local variable?
>>> If so, how is it different from "linkMtuSize"?
>>> It is used again in part 2) of step 2 below.
>>
>> I don't want to say anything about that before checking with the primary
>> author.
> 
> [Mingui] As specified in the text leading the Steps, "linkMtuSize" is a local 
> integer variable for a specific RBridge while "link MTU size" is not a 
> variable but a value that is agreed by two connected RBridges. To avoid the 
> confusion, I changed "linkMtuSize" to "X" and add the text to explain that 
> link MTU size is a value that is agreed by two connected RBridges.
> 
>>
>>> Also, I assume "Lz" is the value previously agreed among the nodes,
>>> but that should be made clear to the reader.
> 
> [Mingui] Agree. Added the word "agreed" in Section 2.
> 
>>>
>>> Nits:
>>> -
>>>
 1. Introduction
>>> ...
   topology. While in this document, a new RECOMMENDED link-wide
>> minimum
   inter-RBridge MTU size, Lz, is specified. By calculating a using Lz
   as specified herein, link-scoped PDUs can be formatted greater than
   the campus-wide Sz up to the link-wide minimum acceptable inter-
   RBridge MTU size potentially improving the efficiency of link
   utilization and speeding link state convergence.
>>>
>>> I cannot parse those two sentences. What does the "While" refer to?

Re: [Gen-art] draft-ietf-v6ops-unique-ipv6-prefix-per-host

[Brian E Carpenter]

On 10/05/2017 03:26, Brzozowski, John wrote:
> The following needs to be addressed:
> 
> "a BCP is whatever the sitting IESG says is a BCP"
> 
> IMO this is subjective and does not yield a consistent experience across IESG 
> cohorts.  For the IETF and work under the same there must be ONE definition 
> of BCP that can be applied uniformly and consistently over time.

There is:
https://tools.ietf.org/html/rfc2026#section-5

I don't see the problem with "best current thinking
on a statement of principle or on what is believed to be the best way
to perform some operations or IETF process function".

Obviously the words "best" and "believed" imply a judgment
call, first by the community and then by the IESG.

  Brian

> 
> John
> +1-484-962-0060
> 
> -Original Message-
> From: Ronald Bonica <rbon...@juniper.net>
> Date: Tuesday, May 9, 2017 at 11:17
> To: Joel Halpern <j...@joelhalpern.com>, John Brzozowski 
> <john_brzozow...@cable.comcast.com>, Brian Carpenter 
> <brian.e.carpen...@gmail.com>, Gunter Van de Velde 
> <gunter.van_de_ve...@nokia.com>, 
> "draft-ietf-v6ops-unique-ipv6-prefix-per-host@ietf.org" 
> <draft-ietf-v6ops-unique-ipv6-prefix-per-host@ietf.org>, 
> "gen-art@ietf.org" <gen-art@ietf.org>
> Subject: RE: [Gen-art] draft-ietf-v6ops-unique-ipv6-prefix-per-host
> 
> Joel,
> 
> I think that you have hit the nail on the head. There is no clearly 
> documented definition of BCP. In reality, the only enforced definition is 
> that "a BCP is whatever the sitting IESG says is a BCP".
> 
> So, rather than arguing the point, why don't we just ask the IESG?
> 
> I will update the shepherds write-up noting that there was a question 
> about whether this document should be BCP or INFO and send the document on to 
> the IESG. We will defer to their judgement regarding the label.
> 
> Ron
> 
> 
> > -Original Message-
> > From: Joel M. Halpern [mailto:j...@joelhalpern.com]
> > Sent: Monday, May 8, 2017 8:31 PM
> > To: Brzozowski, John <john_brzozow...@comcast.com>; Ron Bonica
> > <rbon...@juniper.net>; Brian E Carpenter <brian.e.carpen...@gmail.com>;
> > Van De Velde, Gunter (Nokia - BE/Antwerp)
> > <gunter.van_de_ve...@nokia.com>; draft-ietf-v6ops-unique-ipv6-prefix-
> > per-host@ietf.org; gen-art@ietf.org
> > Subject: Re: [Gen-art] draft-ietf-v6ops-unique-ipv6-prefix-per-host
> > 
> > John, I absolutely agree that this document describes behavior that is 
> useful.
> > And it describes that behavior clearly.
> > One could, on that basis argue for PS status.
> > I think it better fits as informational.
> > I do not think it needs to be marked experimental.
> > I do think it should be published.
> > 
> > There are at least 3 definitions of BCP floating around out there.
> > One clearly does not apply (this is not documenting a widely practiced
> > current usage as far as I know.)  I understand that BCPs are not 
> restricted to
> > that.
> > Another definition is a generally recommended behavior (even if folks 
> do not
> > actually do it, cf BCP 38). I do not think that definition applies to 
> this
> > document.
> > The third, and only enforced definition, is "what the IESG says is a 
> BCP."  Not
> > a very helpful definition, but it is the actual one in use.
> > 
> > Which is why I ended my note by saying that I leave it to the IESG.
> > 
> > Yours,
> > Joel
> > 
> > On 5/8/17 8:04 PM, Brzozowski, John wrote:
> > > Joel,
> > >
> > > Please send the criteria for BCP v Informational so we can all 
> evaluate
> > accordingly.
> > >
> > > The document describes the *behavior* that is expected by UEs based on
> > the network configuration.  This was deliberate, not accidental or 
> assumed.  I
> > am not sure there is anything to disagree about, data pertaining to 
> device
> > behavior is clear and well known.
> > >
> > > John
> > > +1-484-962-0060
> > >
> > > -Original Message-
> > > From: Joel Halpern <j...@joelhalpern.com>
> > > Date: Monday, May 8, 2017 at 10:57
> > > To: Ronald Bonica <rbon...@juniper.net>, Brian Carpenter
> > > 

Re: [Gen-art] draft-ietf-v6ops-unique-ipv6-prefix-per-host

[Brian E Carpenter]

s/The Best Current Practice documented in this note is/The optional Best 
Current Practice documented in this note is/

Regards
   Brian

On 06/05/2017 02:58, Ron Bonica wrote:
> Gunter,
> 
> Thanks much. A brief chat with Joel may clear this up.
> 
>Ron
> 
> 
>> -Original Message-
>> From: Van De Velde, Gunter (Nokia - BE/Antwerp)
>> [mailto:gunter.van_de_ve...@nokia.com]
>> Sent: Friday, May 5, 2017 2:47 AM
>> To: Ron Bonica ; draft-ietf-v6ops-unique-ipv6-prefix-
>> per-host@ietf.org; gen-art@ietf.org
>> Subject: Re: draft-ietf-v6ops-unique-ipv6-prefix-per-host
>>
>> Hi Ron, Gen-art directorate,
>>
>> I’m checking with John on the most optimal way forward. While I am not that
>> keen on the BCP status of the document, it was part of a motivation to split
>> up the original draft on the subject discussing community wifi networks from
>> the address related aspects. John and I will have a discussion on the subject
>> and propose a path to resolution of the issue mentioned by gen-art.
>>
>> G/
>>
>> On 04/05/2017, 21:57, "Ron Bonica"  wrote:
>>
>> Folks,
>>
>> The following is status for draft-ietf-v6ops-unique-ipv6-prefix-per-host:
>>
>> - WG last call complete
>> - OPSDIR, GENART and INTDIR reviews complete
>> - write-up complete
>>
>> The following issue was raised in the GENART Review:
>>
>> " The proposed status seems questionable.  We as a community are not
>> recommending that operators assign unique prefixes to hosts.  This
>> document is saying "if you want to do that, here is a way, using existing 
>> tools,
>> to make that work."  The document also recommends specific setting of
>> other flags (the O flag in the RA, for example) that are not closely coupled 
>> to
>> the particular topic.  This looks like an ordinary Informational RFC.  I 
>> would
>> have no concern with this being published with that label."
>>
>> Could the authors please address this issues. As soon as they have done
>> so, we can send it to the IESG for publication.
>>
>>  
>>  Ron
>>
>>
> 
> ___
> Gen-art mailing list
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art
> 

___
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-spring-resiliency-use-cases-08

[Brian E Carpenter]

Stefano,

I won't argue further about the general issues, they are really
between you and the ADs. About this:

...
>> Minor issue:
>> 
>>
>> The text of section 3 doesn't explain what requirements for SPRING it
>> generates. Really it just describes what any IGP will do anyway.
> 
> 
> not really. Igp’s compute Dijkstra-based shortest paths. Igp’s do not compute 
> repair paths (whatever flavor: dual, parallel, disjoint, etc).

Yes, but that is a comment on DV or SPF algorithms: in principle an IGP could 
use other algorithms, should they be invented. Indeed, you refer to "Automated 
computation by the IGP."

>> How does that impact SPRING? If there is no impact, please say so!
> 
> 
> spring is about source routing and resiliency makes use of source routing. 
> Resiliency makes use of source routing through SR.

Right, but you don't state any *requirements* for SPRING that result from this 
case,
except the very general statement before section 3.1. Maybe that does translate
into specific requirements, but I don't see how.

   Brian

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

Re: [Gen-art] Genart telechat review of draft-ietf-6man-rfc1981bis-06

[Brian E Carpenter]

On 27/04/2017 08:08, Fred Baker wrote:
> 
>> On Apr 26, 2017, at 11:35 AM, Joe Touch  wrote:
>>
>> Hi, Stewart,
>>
>>
>> On 4/26/2017 1:48 AM, Stewart Bryant wrote:
>>>
>>>
>>> On 25/04/2017 19:26, Joe Touch wrote:
 Hi, Stewart,

 ...

> SB>
> SB> Otherwise I would have thought that this was entirely a matter
> SB> for the host whether it wanted to use a Path MTU below the IPv6
> SB> link minimum. Nothing breaks if the host takes a more conservative
> SB> decision.
 I don't agree; the host at that point is violating RFC2460. It should
 never think that an IPv6 link or path with an MTU below what RFC2460
 requires is valid.

 Joe

>>>
>>> That is as maybe, but a host can do more or less what it wants, so
>>> this is surely an
>>> unenforceable constraint, or are you telling me that the receiving
>>> host MUST drop a
>>> fragment that is shorter than this? In which case the question whether
>>> in practice
>>> they do, and whether such a constraint is reasonable.
>>
>> A "path MTU" is a value calculated from information from various sources
>> (attached links, ICMP messages, and perhaps other information), but IMO
>> it's never appropriate to set a "path MTU" smaller than the limit
>> established by IPv6 for a single link.
> 
> You are, of course, quoting RFC 1981:
>A node MUST NOT reduce its estimate of the Path MTU below the IPv6
>minimum link MTU.
> 
>> Individual packets and fragments can be smaller than the MTU, of course.
>> Nothing forces fragments to push up against any MTU limit at all. But I
>> would not describe that has a host changing its path MTU; it's just
>> sending packets.
> 
> I disagree, both on the definition and the action. You are correct in "how 
> the Path MTU is calculated". But the Path MTU, by definition, is the largest 
> packet that can be sent end to end under current routing conditions. It is 
> not, actually, an IP concept: it's a TCP concept if anything, or a transport 
> layer concept (if UDP ever decides to have one). I can imagine TCP probing 
> the Path MTU by trying packets that are larger than its current estimate to 
> see if the estimate is still accurate (1981 section 4), but I can't imagine 
> any reason that TCP would send packets larger than the "largest packet that 
> can be sent end to end under current routing conditions" in the normal case, 
> as those packets will by definition either be fragmented or not arrive.

istm that the robustness principle argues for what Fred is saying. Yes, any 
path that doesn't transmit 1280 byte packets is breaking the law, but (given 
that the protocol police do such a lousy job) if the objective fact is that the 
path only transmits 1279 byte packets, what's best for the user?

Brian

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

Re: [Gen-art] Review of draft-ietf-httpbis-http2-encryption-10

[Brian E Carpenter]

Looks good to me, thanks.

Regards
   Brian

On 27/02/2017 14:22, Mark Nottingham wrote:
> [ editor hat ]
> 
> That all seems reasonable to me; see:
> 
>   https://github.com/httpwg/http-extensions/commit/ca56fd8365
>   https://github.com/httpwg/http-extensions/commit/31c11b4683
> 
> Will incorporate into the next draft when we issue.
> 
> Thanks!
> 
> 
>> On 26 Feb 2017, at 12:20 pm, Brian Carpenter  
>> wrote:
>>
>> Reviewer: Brian Carpenter
>> Review result: Ready with Issues
>>
>> Gen-ART Last Call review of draft-ietf-httpbis-http2-encryption-10
>>
>> 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-httpbis-http2-encryption-10.txt
>> Reviewer: Brian Carpenter
>> Review Date: 2017-02-26
>> IETF LC End Date: 2017-03-06
>> IESG Telechat date: 2017-03-16 
>>
>> Summary: Ready with issues
>> 
>>
>> Comments:
>> -
>>
>> Note: Category is Experimental.
>>
>> Quoting the writeup:
>>
>> 'The primary concern voiced by dissenters has been that widespread
>> deployment might provide a false sense of security, slowing the
>> adoption of "real" HTTPS or confusing users."'
>>
>> FWIW, I share that concern, even with the tag 'Experimental.'
>>
>> Major issue: 
>> 
>>
>> The Abstract should definitely state the above concern. At the
>> moment,
>> it could easily mislead the reader about the value of the solution.
>> I'd like to see the phrase "it is vulnerable to active attacks" in
>> the Abstract.
>>
>> Minor issue:
>> 
>>
>>> 4.4.  Confusion Regarding Request Scheme
>> ...
>>> Therefore, servers need to carefully examine the use of such
>> signals
>>> before deploying this specification.
>>
>> What does "servers" really mean here? I think it means "implementers
>> of server code", or maybe "operators of servers"?
>>
>> Nits:
>> -
>>
>>> 4.1.  Security Indicators
>>>
>>>  User Agents MUST NOT provide any special security indicia when an
>>
>> 'Indicia' is a real word, but I think it's unknown to at least 99% of
>> English speakers. Why not 'indicators' again?
>>
>>
>>
>>
> 
> --
> Mark Nottingham   https://www.mnot.net/
> 
> 

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

Re: [Gen-art] Review of draft-ietf-anima-grasp-09

[Brian E Carpenter]

CCs trimmed.

Thanks Joel. Good comments, we will deal with all of them. We have some basic
questions to answer first, raised by Charlie Perkins' review*, so it will take
a little while.

Regards
   Brian

* https://mailarchive.ietf.org/arch/msg/ietf/PlJ9SgdwT5mdOPqF2fDDIfAeHMQ

On 26/02/2017 08:41, 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-anima-grasp-??
> Reviewer: Joel Halpern
> Review Date: 2017-02-25
> IETF LC End Date: 2017-03-02
> IESG Telechat date: Not scheduled for a telechat
> 
> Summary:
> 
> Major issues:
> 
> Minor issues:
>  Section 2.2 states that routing protocols mainly consider link
> up/down and that "all nodes need a consistent view of the network
> topology".  the first seems an over-generalization, since all routing
> protocols have metrics, and almost all modern routing protocols carry
> significant additional information about the links and nodes.  The
> second statement about consistency is true for some protocols, but is
> not true for external use of BGP nor, as I understand it, for Babel. 
> So it seems again too strong a characterization.  The following
> sentence about information not normally used also seems to be at odds
> with current practice.
> 
> Bullet 1 under SN7 in section 2.2  talks about the potential for
> circular dependence, and then says that this protocol will not provide
> any assistance for that.  given that such dependence may be complex. 
> In particular, given that these dependencies result in separate
> negotiations, the chain of efforts would continue even if the initial
> impetus has timed out.  If a single negotiation causes two dependent
> negotiations, this would seem to have the potential to cause a work
> explosion.
> 
> It is probably considered obvious, but I did not see text
> indicating that GRASP messages with unknown MESSAGE_TYPE should be
> silently ignored.  Or any other definition of the expected behavior
> (should be logged?)
> 
> Nits/editorial comments: 
> In section 3.1 in the definition of Technical Objective the text
> starts by saying that it is a configurable parameter or set of
> parameters.   Most further text refers to a single value, with
> indications that the value may be a complex structure.  Hence, in the
> first part of the definition, the same construction should be used,
> rather than referring to a set of values.  This gets slightly confused
> when section 3.10.4 goes back to talking about multiple parameters for
> an objective.  Consistency please?
> 
> The first paragraph of 3.5.4.1 states that upon receiving a
> discovery request, a recipient will respond, either with the data or
> with a divert.  While this is eventually true, it is misleading.  As
> 3.5.4.2 states, the recipient, if it does not have an answer, will
> relay the request in order to get an answer.  Some mention of this in
> 3.5.4.1 would seem helpful.
> 
> Should the first line of 3.5.5 on negotiation include "(using
> M_REQ_NEG)"?
> 
> 
> 

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

Re: [Gen-art] Review of draft-ietf-6man-rfc1981bis-04

[Brian E Carpenter]

On 17/02/2017 04:59, Stewart Bryant wrote:
> 
> 
> On 14/02/2017 23:00, Templin, Fred L wrote:
>> Unless there is operational assurance of
>> some size X>1280, however, tunnels have to use fragmentation to
>> guarantee that - at a minimum - packets up to 1280 will get through.
> 
> In that case there really needs to be a note about MPLS.
> 
> You can fragment into an IP tunnel, but not an MPLS tunnel, because you 
> cannot fragment the payload as you can in IPv4 and you cannot fragment MPLS.

I'm confused. A tunnel end point that accepts IPv6 packets MUST accept packets
of 1280 bytes (or shorter) and MUST emit them. How it gets them through the
tunnel is irrelevant - if it's an ATM tunnel it has to chop them into 48 byte
fragments and re-assemble them at the other end - if it's an avian carrier 
tunnel
it might have to use several pigeons per packet*. None of this matters to the 
IPv6
nodes concerned; the physical MTU of the tunnel technology is irrelevant except
to the tunnel end points.

   Brian

*In RFC 6214, we didn't consider this, but we should have.

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

Re: [Gen-art] Review of draft-ietf-6man-rfc1981bis-04

[Brian E Carpenter]

On 16/02/2017 10:12, Joe Touch wrote:
> Brian (et al.),
> 
> 
> On 2/10/2017 11:45 AM, Brian E Carpenter wrote:
>>> practice the
>>> Internet breaks the mechanism. However it breaks it is a way that seems
>>> disruptive to some user traffic. The document is really guidance
>>> one how hosts might use  ICMP for optimization, and arguable need
>>> not be a standard at all.
>> I think that's a mischaracterisation of the mechanism (and the draft).
>> PMTUD is not an optimisation. Without it, you get black holes
> PMTUD is an optimization to avoid fragmentation.
> 
> Without it, you use fragmentation (which has overheads and other
> consequences, notably for IPv4).

In IPv6, you don't even know you *need* fragmentation without PMTUD,
since only the source is allowed to fragment. (That was one of the
many failure modes for 6to4, which is why the only safe approach was
to use 1280 always.) 

> However, it is only *with* PMTUD (and ICMP blocking) that you get black
> holes.

True for v4.

   Brian

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

Re: [Gen-art] Review of draft-ietf-6man-rfc1981bis-04

[Brian E Carpenter]

On 10/02/2017 23:20, Stewart Bryant wrote:
> 
> 
> On 10/02/2017 03:25, Brian E Carpenter wrote:
>> Stewart,
>>
>> On 10/02/2017 04:19, Stewart Bryant wrote:
>> ...
>>> I wonder if we would best serve both our future and our heritage
>>> if we declared RFC1981 as historic, and either left the idea there,
>>> or declared it as historic and wrote a new text from a clean start?
>> I don't see that. It's a stable, widely deployed, interoperable
>> mechanism. That is rather orthogonal to the issue that has been raised,
>> which is that faulty ICMPv6 filtering blocks it on many, many paths
>> across the Internet.
> 
> I will not debate whether it is faulty or not, but it seems that in 

It's faulty by the standard of RFC4890 (which is Informational).

> practice the
> Internet breaks the mechanism. However it breaks it is a way that seems
> disruptive to some user traffic. The document is really guidance
> one how hosts might use  ICMP for optimization, and arguable need
> not be a standard at all.

I think that's a mischaracterisation of the mechanism (and the draft).
PMTUD is not an optimisation. Without it, you get black holes.

> 
> My remark about heritage is that this vintage draft is very much a 
> product of
> its time, and really needs modernizing, and after modernizing ought to
> look quite different, and thus maybe we should employ a procedure
> other than a simple replacement.

It's proposed for Internet Standard. That means it must replace the
PS document and must specify the same thing, plus corrections, minus
unused features.

>> ...
>>> It is concerning that the draft does not talk in any detail about
>>> how modern ECMP works, i.e. using the five tuple, and noting that
>>> the PMTU may be different depending on the transport layer port
>>> numbers.
>> Has this problem been analysed for, say, IPv4? And does the real world
>> contain ECMP setups with different MTUs on different paths?
> 
> I don't know if anyone has looked. Since the mechanism is 
> self-correcting albeit
> with some disruption to user traffic it looks to the application and the 
> application
> user, just like the Internet not working for a few moments.
> 
> In a well managed SP network there should not be, but neither should there
> be asymmetric path costs, but there are. The less well manage private
> networks are less well managed.
> 
> 
>>
>>> Given that a very large fraction of packets will traverse an MPLS
>>> network at some point, I am surprised that there is no text talking
>>> about the importance of providing support for this feature in the
>>> MPLS domain. RFC3988 talks to this point, but is only experimental.
>> I don't understand. How does the fact that there might be some MPLS
>> segments along the path affect end-to-end PMTUD?
> 
> The point that RFC3988 makes is that MPLS looks like a single hop to IP 
> and the
> PE has to fragment or has to reply with an ICMP error message to support
> PMTUD. MPLS has ICMP extensions, but I don't know if they integrate to 
> result
> in the right response at the end node.
> 
> My point is that the draft is silent on the subject, and perhaps it 
> should not be.

Well, in general it's silent on tunnels. They have to emulate links,
as stated in section 2. I still don't see why an MPLS tunnel is a special case.

> 
> However your question make me ask a further question. The draft is also 
> silent
> on NATs. Is there any advice needed for people designing and configuring 
> NATs?

Yes, for NAT64/NAT46 - in RFC6145. For NAT66, the advice is "don't".

>>
>>> ==
>>>
>>> If flows [I-D.ietf-6man-rfc2460bis] are in use, an implementation
>>> could use the flow id as the local representation of a path. Packets
>>> sent to a particular destination but belonging to different flows may
>>> use different paths, with the choice of path depending on the flow
>>> id.  This approach will result in the use of optimally sized packets
>>> on a per-flow basis, providing finer granularity than PMTU values
>>> maintained on a per-destination basis.
>>>
>>> SB> How widely is flow-id supported in networks? I thought that the
>>> SB> current position was that it was unreliable as an ECMP indicator
>>> SB> and thus routers tended to glean information from the packet themselves.
>> This is future-proofing. Agreed, usage today is limited.
>>
>> (But it would be better to call it the Flow Label for consistency with other
>> recent RFCs.)
> 
> Well the question is whether it is simply li

Re: [Gen-art] Review of draft-ietf-6man-rfc1981bis-04

[Brian E Carpenter]

Stewart,

On 10/02/2017 04:19, Stewart Bryant wrote:
...
> I wonder if we would best serve both our future and our heritage
> if we declared RFC1981 as historic, and either left the idea there,
> or declared it as historic and wrote a new text from a clean start?

I don't see that. It's a stable, widely deployed, interoperable
mechanism. That is rather orthogonal to the issue that has been raised,
which is that faulty ICMPv6 filtering blocks it on many, many paths
across the Internet.

...
> It is concerning that the draft does not talk in any detail about
> how modern ECMP works, i.e. using the five tuple, and noting that
> the PMTU may be different depending on the transport layer port
> numbers.

Has this problem been analysed for, say, IPv4? And does the real world
contain ECMP setups with different MTUs on different paths?

> Given that a very large fraction of packets will traverse an MPLS
> network at some point, I am surprised that there is no text talking
> about the importance of providing support for this feature in the 
> MPLS domain. RFC3988 talks to this point, but is only experimental.

I don't understand. How does the fact that there might be some MPLS
segments along the path affect end-to-end PMTUD?

> 
> ==
> 
>If flows [I-D.ietf-6man-rfc2460bis] are in use, an implementation
>could use the flow id as the local representation of a path. Packets
>sent to a particular destination but belonging to different flows may
>use different paths, with the choice of path depending on the flow
>id.  This approach will result in the use of optimally sized packets
>on a per-flow basis, providing finer granularity than PMTU values
>maintained on a per-destination basis.
> 
> SB> How widely is flow-id supported in networks? I thought that the 
> SB> current position was that it was unreliable as an ECMP indicator
> SB> and thus routers tended to glean information from the packet themselves.

This is future-proofing. Agreed, usage today is limited.

(But it would be better to call it the Flow Label for consistency with other
recent RFCs.)

I think your other comments are all valuable.

Regards
Brian

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

Re: [Gen-art] Review of draft-ietf-mmusic-sctp-sdp-22

[Brian E Carpenter]

Hi Christer,
On 06/02/2017 03:14, Christer Holmberg wrote:
> Hi Brian,
> 
> Thanks for your review! Please see inline.
> 
> ...
> 
> Comments:
> -
> 
>> Two points I noted in the writeup:
>> "There are existing implementations of earlier versions of the document..."
>>
>> Excellent, but I wonder why we don't see Implementation Status sections 
>> under RFC 6982 in more Last Call drafts.
> 
> Perhaps a topic for an IETF chairs lunch presentation?

Or at least a short reminder!

> 
> I have to admit that I did not know about 6982 (now obsoleted by 7942). My 
> suggestion would to not collect that information for this draft at this point 
> of time, as it could take some time.

Agreed.

>> "IPv6 address examples are not necessary since IP version differences are 
>> immaterial to the purpose of the specification."
>>
>> It's just as easy to give an IPv6 example though, and more future proof.
> 
> I can modify the address in the example, from IPv4 to v6.

As you wish.

> Minor issue: (almost a nit)
> 
> 
> 1.  Introduction
> ...
>>>   NOTE: Due to the characteristics of TCP, usage of 'TCP/DTLS/SCTP'
>>>   will always force ordered and reliable delivery of the SCTP
>>>   packets, which limits the usage of the SCTP options.  Therefore, it is
>>>   RECOMMENDED that TCP is only used in situations where UDP traffic
>>>   is blocked.
>>
>> Why would one choose 'TCP/DTLS/SCTP' rather than just 'TCP/TLS'? I don't 
>> object to it being specified, but since you 
>> don't support multihoming or multiple associations, what is the use case, in 
>> a few words?
> 
> SCTP supports multiple SCTP streams over a single association, and you can 
> still use that with 'TCP/DTLS/SCTP'. E.g, the WebRTC Data Channel protocol 
> uses two streams to realize a data channel.

OK.

(I now remember that I raised essentially the same question when reviewing
draft-ietf-clue-datachannel. Actually I'm glad to see SCTP proving useful.)

> I could modify the first sentence as following:
> 
> "NOTE: Due to the characteristics of TCP, while multiple SCTP streams
>  can still be used, usage of 'TCP/DTLS/SCTP' will always force"

OK

> 
> Nits:
> -
> 
>>> 4.4.2.  SDP Media Description values
>>>
>>>  m= line parameterparameter value(s)
>>> 
>>> --
>>>  : "application"
>>>  : "UDP/DTLS/SCTP" or "TCP/DTLS/SCTP"
>>>  :  UDP port number (for "UDP/DTLS/SCTP")
>>>   TCP port number (for ""UDP/DTLS/SCTP")
>>
>> I think the last line should be: TCP port number (for "TCP/DTLS/SCTP")
> 
> Correct. Will be fixed.
> 
>> There is some inconsistency in the use of quotation marks: "UDP/DTLS/SCTP" 
>> or 'UDP/DTLS/SCTP'
> 
> I'll fix that. I will use single quotes.

Thanks,
Brian

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

[Gen-art] Bounce test, please ignore

[Brian E Carpenter]

This is a test to see if a bounce problem has been resolved.

Avri, if you get this via gen-art, but didn't get one from
tianxiang li  the problem
has indeed been resolved.

Brian

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

Re: [Gen-art] Gen-ART review postings (Was: Re: Review of draft-ietf-geojson-text-sequence-03)

[Brian E Carpenter]

On 25/01/2017 04:27, Dale R. Worley wrote:
...
> Also, is there a reason why people would want to see "Gen-ART last-call
> review of ..." vs. "Gen-ART telechat review of ..."?  It wouldn't make a
> difference to me, but perhaps it is useful input to someone else's
> workflow.

IMHO, it makes a difference. The primary audience for the LC review
is the authors - they are on the hook for *all* last call comments.
The primary audience for the telechat review is the General AD, who
needs to decide how to ballot. Back when I was General AD and Gen-ART
was relatively new, I generally didn't have time to even look at the
LC reviews. Having a distinctive subject on the email was very helpful.

  Brian

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

Re: [Gen-art] Review of draft-ietf-6tisch-minimal-17

[Brian E Carpenter]

FYI, I have checked the -18 draft that just appeared and it
answers all my points. If asked to review it again, I expect
to say "Ready".

Thanks
   Brian Carpenter

On 11/12/2016 11:39, Brian Carpenter wrote:
> Reviewer: Brian Carpenter
> Review result: Almost Ready
> 
> Gen-ART Last Call review of draft-ietf-6tisch-minimal-17
> 
> 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-6tisch-minimal-17.txt
> Reviewer: Brian Carpenter
> Review Date: 2016-12-11
> IETF LC End Date: 2016-12-20
> IESG Telechat date: 2017-01-05
> 
> Summary: Almost Ready
> 
> 
> Comment:
> 
> 
> Although I found some issues, this is a good document which is mainly
> very clear. I was not in a position to check IEEE802.15.4 details.
> 
> It's too late now, but judging by the shepherd's writeup, this draft
> would have been an excellent candidate for an Implementation Status
> section under RFC 6982.
> 
> Major Issues:
> -
> 
> I was very confused for several pages until I went back and read this
> again:
> 
>>   This specification defines operational parameters and procedures
> for
>>   a minimal mode of operation to build a 6TiSCH Network.  The
> 802.15.4
>>   TSCH mode, the 6LoWPAN framework, RPL [RFC6550], and its Objective
>>   Function 0 (OF0) [RFC6552], are used unmodified.
> 
> Then I realised that there is some very basic information missing at
> the beginning
> of the Introduction. That little phrase "the 6LoWPAN framework" seems
> to be the clue.
> What is the 6LoWPAN framework? Which RFCs? I'm guessing it would be
> RFC4944, RFC6282
> and RFC6775, but maybe not. In any case, the very first sentence of
> the Introduction
> really needs to be a short paragraph that explains in outline, with
> citations, how a 
> 6TiSCH network provides IPv6 connectivity over NBMA. With that, the
> rest of the document
> makes sense.
> 
> But related to that, the Abstract is confusing in the same way:
> 
>> Abstract
>>
>>   This document describes a minimal mode of operation for a 6TiSCH
>>   Network.  It provides IPv6 connectivity over a Non-Broadcast
> Multi-
>>   Access (NBMA) mesh...
> 
> "It" is confusing since it seems to refer to this document, which
> hardly
> mentions IPv6 connectivity. I suggest s/It/6TiSCH/.
> 
> As far as I know a Security Considerations section is still always
> required. I understand
> that this document discusses security in detail, but that doesn't
> cancel the
> requirement (https://tools.ietf.org/html/rfc3552#section-5).
> 
> Minor issues:
> -
> 
>> 4.4.  Timeslot Timing
> ...
>>   The RX node needs to send the first bit after the
>>   SFD of the MAC acknowledgment exactly tsTxAckDelay after the end
> of
>>   the last byte of the received packet.
> 
> I don't understand "exactly". Nothing is exact - there is always clock
> jitter.
> Shouldn't there be a stated tolerance rather than "exactly"?
> 
>> 4.5.  Frame Formats
>>
>>   The following sections detail the RECOMMENDED format of link-layer
>>   frames of different types.  A node MAY use a different formats
> (bit
>>   settings, etc)...
> 
> Doesn't this create an interoperability issue for independent
> implementations?
> How can you mix and match implementations that use variants of the
> frame format?
> This seems particularly strange:
> 
>>   The IEEE802.15.4 header of BEACON, DATA and ACKNOWLEDGMENT frames
>>   SHOULD include the Source Address field and the Destination
> Address
>>   field.
> 
> How will it work if some nodes omit the addresses?
> 
>> 4.6.  Link-Layer Security
> ...
>>   For early interoperability testing, value 36 54 69 53 43 48 20 6D
> 69
>>   6E 69 6D 61 6C 31 35 ("6TiSCH minimal15") MAY be used for K1.
> 
> Shouldn't this also say that this value MUST NOT be used in
> operational networks?
> 
> Nits:
> -
> 
>> 1.  Introduction
>>
>>   A 6TiSCH Network provides IPv6 connectivity...
> 
> I would expect to see a reference to [RFC2460] right there.
> 
> Outdated reference: draft-ietf-6lo-paging-dispatch has been published
> as RFC 8025
> 
> 

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

Re: [Gen-art] [mpls] Review of draft-ietf-mpls-tp-linear-protection-mib-11

[Brian E Carpenter]

Fair enough.

Regards
   Brian

On 17/01/2017 08:13, BRUNGARD, DEBORAH A wrote:
> Thanks Benoit-
> 
> As Loa confirmed, we don't see this as an update. It's aligned with how we 
> have been doing the MPLS-TP work e.g. RFC7697 has the same wording.
> 
> Thanks Brian for the careful review-
> Deborah
> 
> 
>> -Original Message-
>> From: mpls [mailto:mpls-boun...@ietf.org] On Behalf Of Benoit Claise
>> Sent: Monday, January 16, 2017 2:35 AM
>> To: Loa Andersson ; Brian Carpenter
>> ; gen-art@ietf.org
>> Cc: m...@ietf.org
>> Subject: Re: [mpls] Review of draft-ietf-mpls-tp-linear-protection-mib-11
>>
>> Loa, Brian,
>>> Brian, et.al.,
>>>
>>> We could of course update 3812 (and 3813), though this would probably
>>> lead to another discussion on what updates means.
>>>
>>> What is refereed to is that there is now another preferred method for
>>> configuration - netconf/yang. In fact this draft doe not change 3812 or
>>> propose a change, so there can not be an update. The document is just
>>> noting that there is a change in the environment, and that for the time
>>> being it will use RFC 3812 as specified.
>>>
>>> Maybe Benoit have a take on this?
>> No strong views on updating RFC 3812, but the text in the intro section
>> and the read-only conformance statement (WriteUp mentions: The MIB
>> module has a read-only conformance statement so that vendors and/or
>> network operators can choose to implement/operate the MIB module as
>> read-only.) do the job IMO.
>>
>> Regards, Benoit
>>>
>>> /Loa
>>>
>>> On 2017-01-16 06:04, Brian Carpenter wrote:
 Reviewer: Brian Carpenter
 Review result: Ready with Issues

 Gen-ART Last Call review of
 draft-ietf-mpls-tp-linear-protection-mib-11

 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-mpls-tp-linear-protection-mib-11.txt
 Reviewer: Brian Carpenter
 Review Date: 2017-01-16
 IETF LC End Date: 2017-01-26
 IESG Telechat date:

 Summary: Ready with minor issues
 

 Comment:
 

 I have not reviewed most details of the MIB module itself. As usual,
 I trust the MIB Doctors.

 "We know of a handful of implementations (or intent to implement)."
 Good. It would have been nice to see an Implementation Status section
 under RFC 6982.

 Minor issues:
 -

At the time of writing, Simple Network Management Protocol (SNMP)
 SET
is no longer recommended as a way to configure MPLS networks as
 was
described in RFC 3812 [RFC3812].

 RFC3812 is explicit that it should be used for configuration:

This MIB module should be used in conjunction with the
companion document [RFC3813] for MPLS based traffic engineering
configuration and management.

 RFC3812 has not been formally updated or obsoleted. Therefore, it
 seems
 to me that the present draft should formally update RFC3812 in this
 respect.

 Does the same issue apply to RFC3813, whose Abstract also states that
 it is used to configure an LSR?

>>>
>>
>> ___
>> mpls mailing list
>> m...@ietf.org
>> https://www.ietf.org/mailman/listinfo/mpls
> 

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

Re: [Gen-art] email notifications in review tool?

[Brian E Carpenter]

On 18/12/2016 10:28, Paul Kyzivat wrote:
> On 12/16/16 5:47 PM, A. Jean Mahoney wrote:
>> You can configure Datatracker to send you a reminder about any
>> outstanding reviews by going to the bottom of the following page:
>> ​
>> https://datatracker.ietf.org/group/genart/reviews/

You need to be signed in, and then it's at the bottom of:
https://datatracker.ietf.org/accounts/review/

Brian

>>
>> Click the "Change Settings" button.
> 
> I find no "Change Settings" button on this page.
> 
>   Thanks,
>   Paul
> 
>> Provide a number in the "Remind days before deadline".
>>
>> Thanks!
>>
>> Jean
>>
>> On 12/16/16 4:13 PM, Fernando Gont wrote:
>>> Folks,
>>>
>>> FWIW, the unicast notifications for assigned documents are really
>>> useful. Thanks so much!
>>>
>>> Question:
>>> Would it be possible to add "configurable unicast email reminders" to
>>> the wish-list for the review tool? e.g., allow the tool to send
>>> notifications on a configurable basis till there are pending actions on
>>> the reviewer's side?
>>>
>>> Thanks!
>>>
>>> Cheers,
>>>
>>
>> ___
>> Gen-art mailing list
>> Gen-art@ietf.org
>> https://www.ietf.org/mailman/listinfo/gen-art
> 
> ___
> Gen-art mailing list
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art
> 

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

[Gen-art] Review tool issue - email From

[Brian E Carpenter]

IMHO there's an important problem with the new tool: the review arrives
with

To: "General Area Review Team (Gen-ART)" 
From: IETF Secretariat 
Cc: draft-whatever@ietf.org

So, if anybody just does Reply, it goes to ietf-secretariat-reply
which is presumably /dev/null, and if they do Reply All it will only
reach the reviewer via the list.

The From is very unfortunate.

Brian
--- Begin Message ---
Reviewer: Jouni Korhonen
Review result: Ready

I think this document is ready for publication.

I have comment, which is just a suggestion concerning document
structure. Currently the updates/changes to RFC4642 are listed in
Introduction. On the other hand there is a specific section for
recommendations. I would move the updates/changes to RFC4642 into its
own section just to make the document a bit more structured.

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

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

Re: [Gen-art] Gen-ART Last Call review of draft-adid-urn-01

[Brian E Carpenter]

Hi Jarrett,

Thanks for your reply - follow-ups in line:
On 29/11/2016 11:04, Jarrett Wold wrote:
> Hi -
> Thanks for the comments.  Please see my responses.
> 
> I used the EIDR draft as a template
> (https://tools.ietf.org/id/draft-pal-eidr-urn-00.txt).  Ad-ID is similar,
> but for advertisements where as EDIR is for program content. 
> 
>> Major Issues:
>> -
>> 
>> This is an informative document that states "Ad-ID is the industry
>> standard..." but doesn't provide a clear normative reference to an industry
>> standard at that point. I assume that would be [SMPTERP2092-1]. If so it
>> should be referenced right there. Unfortunately it's behind a pay wall
>> (http://ieeexplore.ieee.org/document/7291518/). The IESG needs to confirm
>> whether that's acceptable.
> 
>SMPTE can readily make SMPTE RP 2092-1 available privately to IESG
> members (through a liaison).
>Note that SMPTE and ISO exceptionally make standards available for free
> upon request.

OK, this isn't necessarily a show-stopper, but I just wanted to be sure
that the IESG is aware of the situation.

>>>   An Ad-ID Identifier consists of a unique eleven character string
>>>   or a unique twelve character string (video codes only).
>> 
>> What's a "character"? ASCII or UTF-8?
> 
> It is Alphanumeric. Our character coding is UTF-8.  Im not sure if this is
> needed.

Well, neither am I! As I said, I'm not a URN expert, but it seems to me
that avoiding any ambiguity by *specifying* UTF-8 would be better.
RFC5234 leaves it open:
"In certain contexts, a specific mapping (encoding) of values into a
character set (such as ASCII) will be specified."
RFC2141 section 2.2 also leaves it open by allowing for translation
from non-URN characters.

>> The informative reference [Ad-ID-INTRO] doesn't seem to know whether it's a
>> technical appendix or a reference, and the URL that it cites is unhelpful.
>> The material at http://www.ad-id.org/how-it-works/ad-id-structure seems to
>> be what is needed but partly duplicates what is in the draft. Maybe this
>> material is only given here because the actual SMPTE standard costs more
>> than $100? If so, I think it should be clearly labelled as informational
>> material and that only the SMPTE document is definitive.
> 
>   This is meant to just be an introductory text for what an Ad-ID is.  That
> being said, perhaps a link to here is more relevant:
> http://www.ad-id.org/how-it-works/ad-id-structure  This is also referenced
> in SMPTE RP 2092-1

Yes, I think so. If the reader is from the SMPTE world, it may not help,
but for readers from the IETF world I think it will do so.

Regards
   Brian

> Jarrett
> 

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

[Gen-art] Gen-ART Last Call review of draft-adid-urn-01

[Brian E Carpenter]

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-adid-urn-01.txt
Reviewer: Brian Carpenter
Review Date: 2016-11-24
IETF LC End Date: 2016-12-19
IESG Telechat date:

Summary: Almost ready


Comment:


I looked in vain for a shepherd's writeup or even a shepherd. I have no idea 
whether
this draft has gone through adequate expert review, and I am certainly not an 
expert.

Major Issues:
-

This is an informative document that states "Ad-ID is the industry standard..." 
but doesn't
provide a clear normative reference to an industry standard at that point. I 
assume that
would be [SMPTERP2092-1]. If so it should be referenced right there. 
Unfortunately it's
behind a pay wall (http://ieeexplore.ieee.org/document/7291518/). The IESG 
needs to confirm
whether that's acceptable.

>   An Ad-ID Identifier consists of a unique eleven character string
>   or a unique twelve character string (video codes only).

What's a "character"? ASCII or UTF-8?

The informative reference [Ad-ID-INTRO] doesn't seem to know whether it's a 
technical
appendix or a reference, and the URL that it cites is unhelpful. The material at
http://www.ad-id.org/how-it-works/ad-id-structure seems to be what is needed but
partly duplicates what is in the draft. Maybe this material is only given here 
because
the actual SMPTE standard costs more than $100? If so, I think it should be 
clearly
labelled as informational material and that only the SMPTE document is 
definitive.

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

[Gen-art] Gen-ART telechat review of draft-ietf-tsvwg-diffserv-intercon-12

[Brian E Carpenter]

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-tsvwg-diffserv-intercon-12.txt
Reviewer: Brian Carpenter
Review Date: 2016-11-24
IETF LC End Date: 2016-09-08
IESG Telechat date: 2016-12-01

Summary: Ready


Comments:
-

Thanks for fixing my Last Call comments.

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

Re: [Gen-art] Gen-ART telechat review of draft-ietf-netmod-routing-cfg-24

[Brian E Carpenter]

Lada,

I don't feel strongly about it; it's between you and the IESG. FYI, that draft 
is in
the editing stage, so will certainly be an RFC before yours.

Regards
   Brian

On 03/11/2016 04:59, Ladislav Lhotka wrote:
> Brian,
> 
> after looking into draft-ietf-6man-multi-homed-host-10, it seems to me
> that
> 
> - this document doesn't change the set of router configuration
>   parameters specified in RFC 4861,
> 
> - our data model neither prevents nor discourages the settings
>   recommended in draft-ietf-6man-multi-homed-host-10.
> 
> If this is correct, I would say that a normative reference to
> draft-ietf-6man-multi-homed-host-10 is not needed. RFC 4861 is a
> normative reference in routing-cfg only because it defines the
> configuration parameters, which doesn't mean that routing-cfg endorses
> RFC 4861 as a whole.
> 
> Thanks, Lada
> 
> Brian E Carpenter <brian.e.carpen...@gmail.com> writes:
> 
>> This didn't have a chance to be updated before the cutoff,
>> so technically it's still "Ready with Issues", but I am
>> completely happy with Lada's proposed changes.
>>
>> Regards
>>Brian
>>
>> On 25/10/2016 20:56, Ladislav Lhotka wrote:
>>> Hi Brian,
>>>
>>> thank you for the review. Please see my replies inline.
>>>
>>>> On 25 Oct 2016, at 01:07, Brian E Carpenter <brian.e.carpen...@gmail.com> 
>>>> 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
>>>> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
>>>>
>>>> Document: draft-ietf-netmod-routing-cfg-24.txt
>>>> Reviewer: Brian Carpenter
>>>> Review Date: 2016-10-25
>>>> IETF LC End Date: 2016-11-03
>>>> IESG Telechat date: 2016-11-03
>>>>
>>>> Summary: Ready with (minor) issues
>>>> 
>>>>
>>>> Comments:
>>>> -
>>>>
>>>> This seems to be a fine document. FYI I am not a YANG expert.
>>>>
>>>> There is a dissent on a point of principle in the WG archive at
>>>> https://www.ietf.org/mail-archive/web/netmod/current/msg16705.html:
>>>> "Given the historical opposition to revising models once they have been 
>>>> cast as RFCs
>>>> that we have seen within the IETF, then I feel that avoiding incomplete 
>>>> models going
>>>> to RFC is the best course of action."
>>>>
>>>> My understanding is that YANG models are intrinsically extensible, and 
>>>> this is
>>>> noted in the Abstract and Introduction. So I don't find this dissent 
>>>> compelling.
>>>
>>> Indeed, this data model is intended as a basis for other models, e.g. for 
>>> routing protocols. Several such model are already under way.
>>>
>>>>
>>>> Minor Issues:
>>>> -
>>>>
>>>> 1)
>>>> Re on-link-flag and autonomous-flag: Please consider adding a normative
>>>> reference to the approved RFC-to-be draft-ietf-6man-multi-homed-host,
>>>> as well as RFC 4861. That document specifies that having both these flags
>>>> set to False is a legitimate combination, against current expectations.
>>>
>>> Will add.
>>>
>>>>
>>>> 2)
>>>> Did you consider doing anything explicit for ULA prefixes, or would
>>>> this just be handled by special-next-hop/prohibit in border routers?
>>>
>>>
>>> The "ietf-ipv6-router-advertisements" submodule just tries to cover the 
>>> parameters specified in RFC 4861. I understand that configuration specific 
>>> to ULA prefixes is an add-on to this base set, and this can be implemented 
>>> via augmenting the core model from other modules.
>>>  
>>>>
>>>> 3)
>>>>> Appendix B.  Minimum Implementation
>>>>>
>>>>>  Some parts and options of the core routing model, such as user-
>>>>>  defined RIBs, are intended only for advanced routers.  This appendix
>>>>>  gives basic non-normative guidelines for implementing a bare minimum
>>>>>  of available functions.  Such an implementation may be used for hosts
>>>>>  or very simple routers.
>>>>
>>>> IPv6 hosts should definitely not send RFC4861 router advertisements.
>>>> Should that be stated in this appendix?
>>>
>>> Yes, good point, will do.
>>>
>>> Thanks, Lada
>>>
>>> --
>>> Ladislav Lhotka, CZ.NIC Labs
>>> PGP Key ID: E74E8C0C
>>>
>>>
>>>
>>>
>>>
> 

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

[Gen-art] Gen-ART telechat review of draft-ietf-netmod-routing-cfg-24

[Brian E Carpenter]

This didn't have a chance to be updated before the cutoff,
so technically it's still "Ready with Issues", but I am
completely happy with Lada's proposed changes.

Regards
   Brian

On 25/10/2016 20:56, Ladislav Lhotka wrote:
> Hi Brian,
> 
> thank you for the review. Please see my replies inline.
> 
>> On 25 Oct 2016, at 01:07, Brian E Carpenter <brian.e.carpen...@gmail.com> 
>> 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
>> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
>>
>> Document: draft-ietf-netmod-routing-cfg-24.txt
>> Reviewer: Brian Carpenter
>> Review Date: 2016-10-25
>> IETF LC End Date: 2016-11-03
>> IESG Telechat date: 2016-11-03
>>
>> Summary: Ready with (minor) issues
>> 
>>
>> Comments:
>> -
>>
>> This seems to be a fine document. FYI I am not a YANG expert.
>>
>> There is a dissent on a point of principle in the WG archive at
>> https://www.ietf.org/mail-archive/web/netmod/current/msg16705.html:
>> "Given the historical opposition to revising models once they have been cast 
>> as RFCs
>> that we have seen within the IETF, then I feel that avoiding incomplete 
>> models going
>> to RFC is the best course of action."
>>
>> My understanding is that YANG models are intrinsically extensible, and this 
>> is
>> noted in the Abstract and Introduction. So I don't find this dissent 
>> compelling.
> 
> Indeed, this data model is intended as a basis for other models, e.g. for 
> routing protocols. Several such model are already under way.
> 
>>
>> Minor Issues:
>> -
>>
>> 1)
>> Re on-link-flag and autonomous-flag: Please consider adding a normative
>> reference to the approved RFC-to-be draft-ietf-6man-multi-homed-host,
>> as well as RFC 4861. That document specifies that having both these flags
>> set to False is a legitimate combination, against current expectations.
> 
> Will add.
> 
>>
>> 2)
>> Did you consider doing anything explicit for ULA prefixes, or would
>> this just be handled by special-next-hop/prohibit in border routers?
> 
> 
> The "ietf-ipv6-router-advertisements" submodule just tries to cover the 
> parameters specified in RFC 4861. I understand that configuration specific to 
> ULA prefixes is an add-on to this base set, and this can be implemented via 
> augmenting the core model from other modules.
>  
>>
>> 3)
>>> Appendix B.  Minimum Implementation
>>>
>>>  Some parts and options of the core routing model, such as user-
>>>  defined RIBs, are intended only for advanced routers.  This appendix
>>>  gives basic non-normative guidelines for implementing a bare minimum
>>>  of available functions.  Such an implementation may be used for hosts
>>>  or very simple routers.
>>
>> IPv6 hosts should definitely not send RFC4861 router advertisements.
>> Should that be stated in this appendix?
> 
> Yes, good point, will do.
> 
> Thanks, Lada
> 
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
> 
> 
> 
> 
> 

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

[Gen-art] Gen-ART Last Call review of draft-ietf-netmod-routing-cfg-24

[Brian E Carpenter]

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-netmod-routing-cfg-24.txt
Reviewer: Brian Carpenter
Review Date: 2016-10-25
IETF LC End Date: 2016-11-03
IESG Telechat date: 2016-11-03

Summary: Ready with (minor) issues


Comments:
-

This seems to be a fine document. FYI I am not a YANG expert.

There is a dissent on a point of principle in the WG archive at
https://www.ietf.org/mail-archive/web/netmod/current/msg16705.html:
"Given the historical opposition to revising models once they have been cast as 
RFCs
that we have seen within the IETF, then I feel that avoiding incomplete models 
going
to RFC is the best course of action."

My understanding is that YANG models are intrinsically extensible, and this is
noted in the Abstract and Introduction. So I don't find this dissent compelling.

Minor Issues:
-

1)
Re on-link-flag and autonomous-flag: Please consider adding a normative
reference to the approved RFC-to-be draft-ietf-6man-multi-homed-host,
as well as RFC 4861. That document specifies that having both these flags
set to False is a legitimate combination, against current expectations.

2)
Did you consider doing anything explicit for ULA prefixes, or would
this just be handled by special-next-hop/prohibit in border routers?

3)
> Appendix B.  Minimum Implementation
>
>   Some parts and options of the core routing model, such as user-
>   defined RIBs, are intended only for advanced routers.  This appendix
>   gives basic non-normative guidelines for implementing a bare minimum
>   of available functions.  Such an implementation may be used for hosts
>   or very simple routers.

IPv6 hosts should definitely not send RFC4861 router advertisements.
Should that be stated in this appendix?

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

[Gen-art] Gen-ART telechat review of draft-ietf-l3sm-l3vpn-service-model-17

[Brian E Carpenter]

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-l3sm-l3vpn-service-model-17.txt
Reviewer: Brian Carpenter
Review Date: 2016-10-21
IETF LC End Date: 2016-10-11
IESG Telechat date: 2016-10-27

Summary: Almost ready


Comments:
-

Thanks for responding to my LC comments. I have not checked the details of the 
yang.

Minor Issues:
-

This is a point I missed originally but I mentioned it during the discussion:
The model says:

  | | |   | | +--rw match-flow
  | | |   | |   +--rw dscp?inet:dscp
  | | |   | |   +--rw tos? uint8

but tos was obsoleted when dscp was defined by RFC 2474. I don't think
you should include tos. You don't mention ECN, which are the two bits
from tos that are not included in dscp. Those bits are no good for flow
matching because they are variable.  If an operator tries to use the 8 TOS
bits for flow matching but a user supports ECN, the matching will not work
consistently. So I think it's misleading to include this.

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

Re: [Gen-art] Gen-ART Last Call review of draft-ietf-l3sm-l3vpn-service-model-16

[Brian E Carpenter]

That's certainly a valid option, but if you limit it to NAT44
I strongly suggest *calling* it NAT44, not plain NAT.

Regards
   Brian Carpenter

On 10/10/2016 21:55, Qin Wu wrote:
> Not sure we should enumerate all the options in the base model, so your 
> solution makes sense to me.
> 
> -Qin
> -邮件原件-
> 发件人: stephane.litkow...@orange.com [mailto:stephane.litkow...@orange.com] 
> 发送时间: 2016年10月10日 16:29
> 收件人: Brian E Carpenter; draft-ietf-l3sm-l3vpn-service-model@ietf.org; 
> General Area Review Team; l...@ietf.org
> 主题: RE: Gen-ART Last Call review of draft-ietf-l3sm-l3vpn-service-model-16
> 
> For NAT, I would like to hear opinion for other people before doing the 
> change.
> And additional options can be added through augmentation.  One solution is to 
> limit to IPv4 case which is really usual today.
> 
> 
> -Original Message-
> From: Brian E Carpenter [mailto:brian.e.carpen...@gmail.com]
> Sent: Saturday, October 08, 2016 02:08
> To: LITKOWSKI Stephane OBS/OINIS; 
> draft-ietf-l3sm-l3vpn-service-model@ietf.org; General Area Review Team; 
> l...@ietf.org
> Subject: Re: Gen-ART Last Call review of 
> draft-ietf-l3sm-l3vpn-service-model-16
> 
> [N.B. I have added the l3sm list but I am not subscribed]
> 
> On 07/10/2016 20:46, stephane.litkow...@orange.com wrote:
> ...
> 
>>>> 5.12.2.2.  QoS profile
> ...
>> [SLI2] The current model supports classification based on generic DSCP 
>> values. Isn't it enough ?
> 
> Yes, I missed that. I agree, that seems the right level for this model. 
> However, this raises one detail. The model says:
> 
> |  |  | |  |  +--rw match-flow
> |  |  | |  | +--rw dscp?  uint8
> |  |  | |  | +--rw tos?   uint8
> 
> but tos was obsoleted when dscp was defined by RFC 2474. I don't think you 
> should include tos. You don't mention ECN, which are the two bits from tos 
> that are not included in dscp. Those bits are no good for flow matching 
> because they are variable.  If an operator tries to use the 8 TOS bits for 
> flow matching but a user supports ECN, the matching will not work 
> consistently.
> 
> ...
>>> Also, I don't understand how you can separate this issue from Section 
>>> 5.13.2. Transport constraints, where you do discuss parameters relevant to 
>>> diffserv. The whole point about diffserv-intercon is to quantify and 
>>> standardise the constraints at interconnections.
>>> [SLI] We discussed this point when we designed the model, and it was 
>>> simpler to express the transport constraint at vpn level than trying to 
>>> implement them per site. That's why it was decoupled.
>>
>> OK, but you still need a rich set of QoS parameters at that level, and 
>> shouldn't it be the same set?
>>
>> [SLI2] Some of them are equivalent for example low latency/jitter, some are 
>> different as for diversity.
>> I understand your comment, but I think we need a larger discussion on this 
>> topic and this may imply a full remodeling of this part. Let me post a 
>> thread on L3SM list.
> 
> OK.
> 
> ...
>>>> 5.2.2.  Cloud access
>>> ...
>>>>   If NAT is required to access to the cloud, the nat-enabled leaf MUST
>>>>   be set to true.
>>> ...
>>> Although NAT is mentioned, I saw no support for NPTv6 (RFC6296). I also saw 
>>> no mention of private or shared address space (RFC1918, RFC4193 or RFC6598).
>>>
>>> [SLI] NAT is a generic term, it only mentions that address translation is 
>>> needed but does not tell what technology will be used. Nothing prevents SP 
>>> to implement NPTv6.
>>
>> No, but the IETF strongly recommends against NAT66, while having specs for 
>> NAT44, NAT64 and NPTv6.
>> Hiding these distinctions under the buzzword "NAT" is misleading.
>>
>> [SLI2] That was done for simplification purpose, could you list the 
>> different options that you would like to see in this model ? To be honest, 
>> I'm not fully aware of all the necessary combinations, so help would be 
>> required.
> 
> I think the three cases I mentioned are sufficient for a start, but (getting 
> back to Benoit's point) we could quickly get into configuration detail. So we 
> have
> 
> NAT44 - which requires an outside ipv4-address.
> 
> NAT64 (for an IPv6-only network requiring IPv4 access) - which requires an 
> outside ipv4-address and an inside WKP (well-known ipv6-prefix).
> (NAT64 implies DNS64, but I don't think that is needed in the model.)
> 
> NPTv6 - which requires an outside ipv6

Re: [Gen-art] Gen-ART Last Call review of draft-ietf-l3sm-l3vpn-service-model-16

[Brian E Carpenter]

[N.B. I have added the l3sm list but I am not subscribed]

On 07/10/2016 20:46, stephane.litkow...@orange.com wrote:
...

>>> 5.12.2.2.  QoS profile
...
> [SLI2] The current model supports classification based on generic DSCP 
> values. Isn't it enough ?

Yes, I missed that. I agree, that seems the right level for this model. However,
this raises one detail. The model says:

|  |  | |  |  +--rw match-flow
|  |  | |  | +--rw dscp?  uint8
|  |  | |  | +--rw tos?   uint8

but tos was obsoleted when dscp was defined by RFC 2474. I don't think
you should include tos. You don't mention ECN, which are the two bits
from tos that are not included in dscp. Those bits are no good for flow
matching because they are variable.  If an operator tries to use the 8 TOS
bits for flow matching but a user supports ECN, the matching will not work
consistently.

...
>> Also, I don't understand how you can separate this issue from Section 
>> 5.13.2. Transport constraints, where you do discuss parameters relevant to 
>> diffserv. The whole point about diffserv-intercon is to quantify and 
>> standardise the constraints at interconnections.
>> [SLI] We discussed this point when we designed the model, and it was simpler 
>> to express the transport constraint at vpn level than trying to implement 
>> them per site. That's why it was decoupled.
> 
> OK, but you still need a rich set of QoS parameters at that level, and 
> shouldn't it be the same set?
> 
> [SLI2] Some of them are equivalent for example low latency/jitter, some are 
> different as for diversity.
> I understand your comment, but I think we need a larger discussion on this 
> topic and this may imply a full remodeling of this part. Let me post a thread 
> on L3SM list.

OK.

...
>>> 5.2.2.  Cloud access
>> ...
>>>   If NAT is required to access to the cloud, the nat-enabled leaf MUST
>>>   be set to true.
>> ...
>> Although NAT is mentioned, I saw no support for NPTv6 (RFC6296). I also saw 
>> no mention of private or shared address space (RFC1918, RFC4193 or RFC6598).
>>
>> [SLI] NAT is a generic term, it only mentions that address translation is 
>> needed but does not tell what technology will be used. Nothing prevents SP 
>> to implement NPTv6.
> 
> No, but the IETF strongly recommends against NAT66, while having specs for 
> NAT44, NAT64 and NPTv6.
> Hiding these distinctions under the buzzword "NAT" is misleading.
> 
> [SLI2] That was done for simplification purpose, could you list the different 
> options that you would like to see in this model ? To be honest, I'm not 
> fully aware of all the necessary combinations, so help would be required.

I think the three cases I mentioned are sufficient for a start, but (getting 
back to
Benoit's point) we could quickly get into configuration detail. So we have

NAT44 - which requires an outside ipv4-address.

NAT64 (for an IPv6-only network requiring IPv4 access) - which requires
an outside ipv4-address and an inside WKP (well-known ipv6-prefix).
(NAT64 implies DNS64, but I don't think that is needed in the model.)

NPTv6 - which requires an outside ipv6-prefix.

(There are also possible NAT444 and XLAT464 cases with added complexity,
but let's leave them for now.)

So the three cases are different. I think you would need something like

  | | +--rw nat44-enabled?boolean
  | | +--rw customer-nat44-address?   inet:ipv4-address
  | | +--rw nat64-enabled?boolean
  | | +--rw customer-nat64-address?   inet:ipv4-address
  | | +--rw customer-nat64-wkp?   inet:ipv6-prefix
  | | +--rw nptv6-enabled?boolean
  | | +--rw customer-nptv6-prefix?inet:ipv6-prefix

If you go that way it needs a quick check on the BEHAVE list, where
NAT expertise exists.

Regards
   Brian

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

Re: [Gen-art] Gen-ART Last Call review of draft-ietf-l3sm-l3vpn-service-model-16

[Brian E Carpenter]

Just front-posting for this point:

> Indeed, we should pay attention that this Service YANG model doesn't 
> turn into a full device configuration model.

Understood. I guess my concern is that people may make false assumptions
from the service model about what it implies for configuration. Thus
"NAT" might falsely imply "NAT66", and no doubt there are other examples.

I will think about this before replying to Stephane again.

Regards
   Brian

On 07/10/2016 22:14, Benoit Claise wrote:
> Hi Brian, all,
> 
> [including the L3SM mailing list]
> 
> It will be a very useful addition to add a few words about : "We did not 
> wanted to add all the possible options, but the most current ones. New 
> scenarios can always been added through augmentations.", as mentioned by 
> Stephane.
> 
> In terms of QoS, I believe that this service model already contains too 
> much details already
> As I wrote in my AD review, 
> https://mailarchive.ietf.org/arch/msg/l3sm/0JUa85ioK_mtw2GtRM_FKP53guQ:
> 
> . QoS Classification
> I see match statements like in the ACL YANG model in NETMOD, I see QoS
> parameters, and I wonder if it makes sense to have so many details in a
> service model. Are you really sure that you don't have too much in that
> area? Don't you need just need a very generic mechanism such as the
> tc-latency, tc-jitter, tc-bandwidth, tc-path-diversity, and
> tc-site-diversity for gold, silver and bronze?
> 
> Indeed, we should pay attention that this Service YANG model doesn't 
> turn into a full device configuration model.
>  From the charter:
> 
> It needs to be clearly understood that this L3VPN service model is
> not an L3VPN configuration model. That is, it does not provide
> details for configuring network elements or protocols. Instead it
> contains the characteristics of the service, as discussed between
> the operators and their customers. A separate process is responsible
> for mapping this service model onto the protocols and network
> elements depending on how the network operator chooses to realise
> the service.
> 
> We should focus on the most common options, from an operator point of 
> view. Otherwise, we could be adding features forever.
> IMO, it's time to declare victory on this service YANG model.
> 
> Regards, Benoit
>> Hi Brian,
>>
>> More inline.
>>
>> Brgds,
>>
>> -Original Message-
>> From: Brian E Carpenter [mailto:brian.e.carpen...@gmail.com]
>> Sent: Thursday, October 06, 2016 21:58
>> To: LITKOWSKI Stephane OBS/OINIS; 
>> draft-ietf-l3sm-l3vpn-service-model@ietf.org; General Area Review Team
>> Subject: Re: Gen-ART Last Call review of 
>> draft-ietf-l3sm-l3vpn-service-model-16
>>
>> Stephane,
>>
>> Thanks for the response and the proposed updates. Some follow-up on a few 
>> points:
>>
>> On 06/10/2016 21:46, stephane.litkow...@orange.com wrote:
>> ...
>>>> 5.3.2.2.1.  IP addressing
>>> ...
>>>> o  slaac : enables stateless address autoconfiguration ([RFC4862]).
>>>>   This is applicable only for IPv6.
>>> You can't stop there. Within SLAAC, privacy addresses (RFC4941) may or may 
>>> not be allowed by an operator, and opaque addresses (RFC7217) may be 
>>> required. So two more Boolean properties are needed.
>>>
>>> Also, DHCPv6, SLAAC and static addresses may coexist; they are not mutually 
>>> exclusive. I'm not sure if your model allows that.
>>>
>>> [SLI] We did not wanted to add all the possible options, but the most 
>>> current ones. New scenarios can always been added through augmentations.
>> OK. I think a general note in the Introduction saying that would be very 
>> useful.
>>
>> [SLI2] I added a note in a new "feature and augmentation" paragraph that I 
>> already created to accommodate another comment.
>>
>>>
>>>> 5.12.2.1.  QoS classification
>>> This is too simple. At least, it needs to be able to handle a port range, 
>>> not just a single port number.
>>>
>>> [SLI] What we need to identify is a particular application running on a 
>>> specific port, we are not defining a router configuration framework here.
>> No, but there are applications that run on multiple ports and it's a bit 
>> clumsy to require a separate classifier for each port.
>>
>> [SLI2] I'm adding it.
>>
>>>
>>>> 5.12.2.2.  QoS profile
>>> rate-limit, priority-level, and guaranteed-bw-percent may be OK for MPLS, 
>>> but they do n

[Gen-art] Gen-ART telechat review of draft-ietf-ospf-two-part-metric-09

[Brian E Carpenter]

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-ospf-two-part-metric-09.txt
Reviewer: Brian Carpenter
Review Date: 2016-10-07
IETF LC End Date: 2016-08-15
IESG Telechat date: 2016-10-13

Summary: Ready (with nit)


Comments:
-

Thanks for responding to my last call comments. I have no objection
to the other changes but they lead to:

Nit:


Delete "5340" from the Updates: header.

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

Re: [Gen-art] Gen-ART Last Call review of draft-ietf-l3sm-l3vpn-service-model-16

[Brian E Carpenter]

Stephane,

Thanks for the response and the proposed updates. Some follow-up on a few 
points:

On 06/10/2016 21:46, stephane.litkow...@orange.com wrote:
...
>> 5.3.2.2.1.  IP addressing
> ...
>>o  slaac : enables stateless address autoconfiguration ([RFC4862]).
>>  This is applicable only for IPv6.
> 
> You can't stop there. Within SLAAC, privacy addresses (RFC4941) may or may 
> not be allowed by an operator, and opaque addresses (RFC7217) may be 
> required. So two more Boolean properties are needed.
> 
> Also, DHCPv6, SLAAC and static addresses may coexist; they are not mutually 
> exclusive. I'm not sure if your model allows that.
> 
> [SLI] We did not wanted to add all the possible options, but the most current 
> ones. New scenarios can always been added through augmentations.

OK. I think a general note in the Introduction saying that would be very useful.

> 
> 
>> 5.12.2.1.  QoS classification
> 
> This is too simple. At least, it needs to be able to handle a port range, not 
> just a single port number.
> 
> [SLI] What we need to identify is a particular application running on a 
> specific port, we are not defining a router configuration framework here.

No, but there are applications that run on multiple ports and it's a bit clumsy
to require a separate classifier for each port.

> 
> 
>> 5.12.2.2.  QoS profile
> 
> rate-limit, priority-level, and guaranteed-bw-percent may be OK for MPLS, but 
> they do not capture the needed parameters for differentiated services. I 
> could write an essay here, but I think the best starting point is 
> draft-ietf-tsvwg-diffserv-intercon.
> [SLI] Again, we captured the most used parameters by service providers. The 
> goal is not to provide all. But If you see a specific parameter that is 
> widely used and not implemented here, feel free to point it.

Diffserv DSCP values are widely used. I suggested diffserv-intercon because it 
proposes
a specific subset useful at network boundaries, but there is also RFC 5127 and 
related
work for WebRTC (https://tools.ietf.org/html/draft-ietf-tsvwg-rtcweb-qos).

> 
> Also, I don't understand how you can separate this issue from Section 5.13.2. 
> Transport constraints, where you do discuss parameters relevant to diffserv. 
> The whole point about diffserv-intercon is to quantify and standardise the 
> constraints at interconnections.
> [SLI] We discussed this point when we designed the model, and it was simpler 
> to express the transport constraint at vpn level than trying to implement 
> them per site. That's why it was decoupled.

OK, but you still need a rich set of QoS parameters at that level, and shouldn't
it be the same set?

> I recommend having TSVWG review sections 5.12 and 5.13.
> 
> 
> Minor Issues:
> -
> 
>> 5.2.2.  Cloud access
> ...
>>   If NAT is required to access to the cloud, the nat-enabled leaf MUST
>>   be set to true.
> ...
> Although NAT is mentioned, I saw no support for NPTv6 (RFC6296). I also saw 
> no mention of private or shared address space (RFC1918, RFC4193 or RFC6598).
> 
> [SLI] NAT is a generic term, it only mentions that address translation is 
> needed but does not tell what technology will be used. Nothing prevents SP to 
> implement NPTv6.

No, but the IETF strongly recommends against NAT66, while having specs for 
NAT44, NAT64 and NPTv6.
Hiding these distinctions under the buzzword "NAT" is misleading.

> The non working point is that the customer-nat-address is an IPv4 type which 
> is a mistake ... it could be IPv6 also.

But it's not a NAT address, it's an NPTv6 prefix. A different animal.

...

Regards
Brian

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

[Gen-art] Gen-ART Last Call review of draft-ietf-l3sm-l3vpn-service-model-16

[Brian E Carpenter]

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-l3sm-l3vpn-service-model-16.txt
Reviewer: Brian Carpenter
Review Date: 2016-10-04
IETF LC End Date: 2016-10-11
IESG Telechat date:

Summary: Ready with issues


Comments:
-

I assume that the minor fixes mentioned in the shepherd's writeup will
be done. I have not checked the details of the yang.

Maror Issues:
-

> 5.3.2.2.1.  IP addressing
...
>o  slaac : enables stateless address autoconfiguration ([RFC4862]).
>  This is applicable only for IPv6.

You can't stop there. Within SLAAC, privacy addresses (RFC4941) may or
may not be allowed by an operator, and opaque addresses (RFC7217)
may be required. So two more Boolean properties are needed.

Also, DHCPv6, SLAAC and static addresses may coexist; they are not
mutually exclusive. I'm not sure if your model allows that.

> 5.12.2.1.  QoS classification

This is too simple. At least, it needs to be able to
handle a port range, not just a single port number.

> 5.12.2.2.  QoS profile

rate-limit, priority-level, and guaranteed-bw-percent may be OK for
MPLS, but they do not capture the needed parameters for differentiated
services. I could write an essay here, but I think the best starting
point is draft-ietf-tsvwg-diffserv-intercon.

Also, I don't understand how you can separate this issue from
Section 5.13.2. Transport constraints, where you do discuss parameters
relevant to diffserv. The whole point about diffserv-intercon is
to quantify and standardise the constraints at interconnections.

I recommend having TSVWG review sections 5.12 and 5.13.

Minor Issues:
-

> 5.2.2.  Cloud access
...
>   If NAT is required to access to the cloud, the nat-enabled leaf MUST
>   be set to true.
...
Although NAT is mentioned, I saw no support for NPTv6 (RFC6296). I also
saw no mention of private or shared address space (RFC1918, RFC4193 or RFC6598).

...
> How the restrictions will be configured on network elements is out of
> scope of this document and will be specific to each deployment.

"Each deployment"? I would have thought that this might be uniform for
a given suite of software+hardware implementing the model, or even that
standard practice might emerge with experience. So I suggest to truncate
this sentence:
 How the restrictions will be configured on network elements is out of
 scope of this document.

>   
>   ZKITYHJ054687
...

Suddenly we have two chunks of XML with no explanation. Why are we using XML?
Should these be captioned as figures? Some text explaining the usage of XML is
missing. Since there are XML configuration fragments in many places later in
the document, this could be in Section 1.1. Terminology.

> 5.3.2.2.1.  IP addressing
>
>   IP subnet can be configured for either transport protocols.  For a
>   dual stack connection, two subnets will be provided, one for each
>   transport layer.

Surely you don't mean 'transport layer'? And I think you mean 'prefix'
rather than 'subnet'.
...
>o  provider-dhcp : the provider will provide DHCP service for
>  customer equipments, this is applicable to both IPv4 and IPv6
>  addressing.

I find it confusing that you use provider-dhcp for both DHCP and
DHCPv6. They are different protocols. I understand that the usage
is inside container ipv6 {} or container ipv4 {} but it's still
confusing.

> 5.3.2.3.  Inheritance of parameters between site and site-network-access

This section raises more questions than it answers - especially
questions about how the orchestrator works. I suggest adding
a comment along the lines of "out of scope... requires further study."

> 5.6.6.1.  Multihoming
>
>   The customer wants to create a multihomed site.

How do you express, for IPv6, that the customer has multiple IPv6
prefixes, one per ISP? (RFC7157 situation) This is not clear
in section 5.3.2. Site network accesses.

> 5.9.  Security

Don't you want a placeholder for firewall policy elements?

> 5.11.  Routing protocols
>
>   Routing-protocol defines which routing protocol must be activated
>   between the provider and the customer router.  The current model
>   support : bgp, rip, ospf, static, direct, vrrp.

As with DHCP, I find it confusing. There are two BGPs, two RIPs,
and two OSPFs, and using the same name for IPv4 and IPv6 seems wrong.
(VRRPv3 seems to be the same for both IP versions, but do you need
to distinguish it from VRRPv2?).

> 9.  Security Considerations

It would be useful to refer here to Section 5.9. Security.

Nits:
-

Watch for undefined jargon (VRF is an example).

There are a lot of minor grammatical or typographical errors that make
the text more difficult to read. Quite a lot 

Re: [Gen-art] Gen-ART telechat review of draft-ietf-nfsv4-multi-domain-fs-reqs-09

[Brian E Carpenter]

Hi,

Thanks for version -10. I appreciate the clarification to the title etc.

(All the same, a BCP is just as mandatory as a Draft Standard. But it's
a judgment call, of course.)

Regards
   Brian Carpenter

On 30/08/2016 07:50, Adamson, Andy wrote:
> 
>> On Aug 26, 2016, at 1:10 AM, Brian E Carpenter <brian.e.carpen...@gmail.com> 
>> 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 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
>> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
>>
>> Document: draft-ietf-nfsv4-multi-domain-fs-reqs-09.txt
>> Reviewer: Brian Carpenter
>> Review Date: 2016-08-26
>> IETF LC End Date: 2016-07-06
>> IESG Telechat date: 2016-09-01
>>
>> Summary: Ready with issues
>> 
>>
>> Comment: After my Last Call review I expected to see a new version,
>>  but that hasn't happened yet.
> 
> Hi Brian
> 
> Thanks for the review. I left draft-09 until I heard other comments. 
> 
>>
>>
>> Minor issue:
>> 
>>
>> "This document provides guidance on the deployment of..."
>>
>> I understand that the AD suggested the standards track, but the document
>> reads more like a BCP than a Proposed Standard to me. As I read through the
>> document, it describes alternatives and differing scenarios.
> 
> 
> This latest round of comments - including the SecDir review from Russ Housley 
> shows that there is still an impedence mis-match between the title/abstract 
> and the intended status of Standards Track versus an Informational draft or 
> best practices.
> 
> I feel that the use of "Guidelines" in the title, and "guidance" in the 
> abstract point to an Informational draft rather than a Standards track.
> 
> This draft is a Proposed Standard (not an Informational or BCP) because the 
> MUST and REQUIRED noted in section 6 of the doc are absolute requirements for 
> an NFSv4 multi-domain file name space to work. These can not be BCP as an 
> NFSv4 multi-domain file name space will _not_ work without these requirements.
> 
> I have completed a draft-ietf-nfsv4-multi-domain-fs-reqs-10 with the 
> following changes:
> 
> 1) The title to be changed from
> 
> "Multiple NFSv4 Domain Namespace Deployment Guidelines"
> 
> to
> 
> "Multiple NFSv4 Domain Namespace Deployment Requirements"
> 
> 
> 2) The first sentence in the abstract (and in the introduction) to be changed 
> from
> 
>This document provides guidance on the deployment of the NFSv4
>protocols for the construction of an NFSv4 file name space in
>environments with multiple NFSv4 Domains.
> 
> to
>This document presents requirements on the deployment of the NFSv4
>protocols for the construction of an NFSv4 file name space in
>environments with multiple NFSv4 Domains. 
> 
> 
> Another common area of comment concerned the “Stand-alone Examples" examples 
> section 5 and "Stand-alone Examples and Multiple NFSv4 Domain Namespaces” 
> section 8. These section describe "alternatives and differing scenarios” to 
> highlight the need for the requirements described in section 6.
> 
> I addressed the example sections comments by adding clarifying text to each 
> of these sections as well as moving the second section from 8 to section 7.
> 
> I have also addressed the remaining comments from Brian, Russ, Alexey 
> Melnikov, and Kathleen Moriarty.
> 
> I’ll upload the new draft soon.
> 
> —>Andy
> 
>>
>> Nits:
>> -
>>
>>  ** Downref: Normative reference to an Informational RFC: RFC 1813
>>
>> This reference was added in the -09 version. I believe it should be
>> Informative instead of Normative.
>>
>>  ** Obsolete normative reference: RFC 1831 (Obsoleted by RFC 5531)
>>
>> This needs to be fixed.
> 

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

Re: [Gen-art] Gen-ART Last Call review of draft-ietf-tsvwg-diffserv-intercon-08

[Brian E Carpenter]

Ruediger,

Thanks and regards,
   Brian

On 29/08/2016 19:19, ruediger.g...@telekom.de wrote:
> Hi Brian,
> 
> thanks. I've submitted a new version without the nits (I applied "RFC " 
> notation for non-reference mentions).
> 
> Regards,
> 
> Ruediger
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-diffserv-intercon/
> 
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-tsvwg-diffserv-intercon-09
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-diffserv-intercon-09
> 
> 
> -Ursprüngliche Nachricht-
> Von: Brian E Carpenter [mailto:brian.e.carpen...@gmail.com] 
> Gesendet: Montag, 29. August 2016 06:47
> An: draft-ietf-tsvwg-diffserv-intercon@ietf.org; General Area Review Team
> Betreff: Gen-ART Last Call review of draft-ietf-tsvwg-diffserv-intercon-08
> 
> 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 
> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
> 
> Document: draft-ietf-tsvwg-diffserv-intercon-08.txt
> Reviewer: Brian Carpenter
> Review Date: 2016-08-29
> IETF LC End Date: 2016-09-08
> IESG Telechat date:
> 
> Summary: Ready with nits
> 
> 
> Comments:
> -
> 
> 1. I was co-chair of the original diffserv WG, and I have tracked this draft 
> throughout its life and influenced some of its content. I have re-read it 
> carefully for this review.
> 
> 2. I believe it is correctly positioned as Informational. It might become a 
> candidate for BCP with deployment experience.
> 
> Nits:
> -
> 
> Section 4 mentions RFC2575, certainly a typo for RFC2475.
> 
> Non-reference mentions of RFCs are inconsistent, e.g. both "RFC4594" and  
> "RFC 4594" occur.
> 

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

[Gen-art] Gen-ART Last Call review of draft-ietf-tsvwg-diffserv-intercon-08

[Brian E Carpenter]

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-tsvwg-diffserv-intercon-08.txt
Reviewer: Brian Carpenter
Review Date: 2016-08-29
IETF LC End Date: 2016-09-08
IESG Telechat date:

Summary: Ready with nits


Comments:
-

1. I was co-chair of the original diffserv WG, and I have tracked this draft
throughout its life and influenced some of its content. I have re-read it
carefully for this review.

2. I believe it is correctly positioned as Informational. It might become a
candidate for BCP with deployment experience.

Nits:
-

Section 4 mentions RFC2575, certainly a typo for RFC2475.

Non-reference mentions of RFCs are inconsistent, e.g. both "RFC4594" and  "RFC 
4594" occur.

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

[Gen-art] Gen-ART telechat review of draft-ietf-nfsv4-multi-domain-fs-reqs-09

[Brian E Carpenter]

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-nfsv4-multi-domain-fs-reqs-09.txt
Reviewer: Brian Carpenter
Review Date: 2016-08-26
IETF LC End Date: 2016-07-06
IESG Telechat date: 2016-09-01

Summary: Ready with issues


Comment: After my Last Call review I expected to see a new version,
 but that hasn't happened yet.


Minor issue:


"This document provides guidance on the deployment of..."

I understand that the AD suggested the standards track, but the document
reads more like a BCP than a Proposed Standard to me. As I read through the
document, it describes alternatives and differing scenarios.

Nits:
-

  ** Downref: Normative reference to an Informational RFC: RFC 1813

This reference was added in the -09 version. I believe it should be
Informative instead of Normative.

  ** Obsolete normative reference: RFC 1831 (Obsoleted by RFC 5531)

This needs to be fixed.

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

Re: [Gen-art] Gen-ART Last Call review of draft-ietf-ospf-two-part-metric-05

[Brian E Carpenter]

On 10/08/2016 14:09, Acee Lindem (acee) wrote:
> Hi Brian, 
> I believe we got a warning from xml2rfc when we didn’t use the pre-2008
> disclaimer (since the draft “updates” RFC 2328).

That's correct, it generates such a warning, but it's more in the form
of a question ("do you need this?" not "you need this!"). It's confusing.
Most times, it's not needed.

I was in at the birth of that waiver; it drove me nuts that we had to allow
for it.

   Brian

> Thanks,
> Acee 
> 
> On 8/8/16, 6:32 PM, "Brian E Carpenter" <brian.e.carpen...@gmail.com>
> wrote:
> 
>> Hi,
>>
>> That's all good. With the clarifcations, I think the "Updates" is OK too.
>> I still don't think you need the pre-2008 disclaimer, but that's a nit.
>>
>> Thanks
>>   Brian
>>
>> On 09/08/2016 09:27, Jeffrey (Zhaohui) Zhang wrote:
>>> Please see -07 version that should address the issues raised by Brian
>>> (except that "update" part).
>>>
>>> https://tools.ietf.org/html/draft-ietf-ospf-two-part-metric-07
>>>
>>> Thanks.
>>> Jeffrey
>>>
>>>> -Original Message-
>>>> From: Acee Lindem (acee) [mailto:a...@cisco.com]
>>>> Sent: Monday, August 08, 2016 5:02 PM
>>>> To: Brian E Carpenter <brian.e.carpen...@gmail.com>;
>>>> draft-ietf-ospf-two-
>>>> part-metric@ietf.org; General Area Review Team <gen-art@ietf.org>
>>>> Subject: Re: Gen-ART Last Call review of
>>>> draft-ietf-ospf-two-part-metric-
>>>> 05
>>>>
>>>> Hi Brian,
>>>>
>>>> See one inline.
>>>>
>>>> On 8/8/16, 4:18 PM, "Brian E Carpenter" <brian.e.carpen...@gmail.com>
>>>> wrote:
>>>>
>>>>> Hi Acee,
>>>>>
>>>>> Thanks, just a few points in line:
>>>>>
>>>>> On 09/08/2016 05:47, Acee Lindem (acee) wrote:
>>>>>> Hi Brian,
>>>>>>
>>>>>> Thanks much for the thorough review. Jeffrey and I discussed your
>>>>>> comments
>>>>>> this morning. See responses to your major/minor comments below. We
>>>>>> will
>>>>>> incorporate all the nits.
>>>>>>
>>>>>> On 8/6/16, 9:38 PM, "Brian E Carpenter" <brian.e.carpen...@gmail.com>
>>>>>> 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
>>>>>>> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
>>>>>>>
>>>>>>> Document: draft-ietf-ospf-two-part-metric-05.txt
>>>>>>> Reviewer: Brian Carpenter
>>>>>>> Review Date: 2016-08-07
>>>>>>> IETF LC End Date: 2016-08-15
>>>>>>> IESG Telechat date:
>>>>>>>
>>>>>>> Summary: Almost ready
>>>>>>> 
>>>>>>>
>>>>>>> Major issues:
>>>>>>> -
>>>>>>>
>>>>>>>> Updates: 2328, 5340 (if approved)
>>>>>>>
>>>>>>> If that is so, the text needs to explain what is changed in those
>>>>>>> two
>>>>>>> RFCs. Since
>>>>>>> this draft describes an "optional extension" to OSPF, it does not
>>>>>>> obviously update
>>>>>>> them. Is any text in those two RFCs made invalid by this draft?
>>>>>>
>>>>>> This has been an ongoing debate as to whether an RFC the augments an
>>>>>> existing draft updates it or whether it must actually change the
>>>>>> existing
>>>>>> behavior. In this case, the SPF calculation is modified as specified
>>>>>> in
>>>>>> section 3.6 but only when the new Network-to-Router metric is
>>>>>> advertised.
>>>>>> In RFC 2328 and RFC 5340, this cost is always zero (i.e., cost to
>>>>>> reach
>>>>>&

Re: [Gen-art] Gen-ART Last Call review of draft-ietf-clue-datachannel-13

[Brian E Carpenter]

Thanks!

Of course, if asked to re-review this for the telechat, the review will just 
say "Ready".

Regards
   Brian

On 10/08/2016 07:05, Christer Holmberg wrote:
> Submitted.
> 
> Regards,
> 
> Christer
> 
> -Original Message-
> From: Alissa Cooper [mailto:ali...@cooperw.in] 
> Sent: 09 August 2016 21:53
> To: Christer Holmberg <christer.holmb...@ericsson.com>
> Cc: Brian E Carpenter <brian.e.carpen...@gmail.com>; 
> draft-ietf-clue-datachannel@ietf.org; General Area Review Team 
> <gen-art@ietf.org>
> Subject: Re: Gen-ART Last Call review of draft-ietf-clue-datachannel-13
> 
> 
>> On Aug 8, 2016, at 12:29 PM, Christer Holmberg 
>> <christer.holmb...@ericsson.com> wrote:
>>
>> Hi,
>>
>> I've created a new version of the draft, based on Brian's comments. It's not 
>> yet submitted, but can be found at GitHub:
>>
>> https://github.com/cdh4u/draft-clue-datachannel/blob/master/draft-ietf
>> -clue-datachannel.txt
>>
>> The only change is to add a reference to the club protocol draft in the 
>> Introduction section.
>>
>> Alissa, please let me know when I can submit the new version :)
> 
> You can go ahead and submit.
> 
> Thanks,
> Alissa
> 
>>
>> Thanks!
>>
>> Regards,
>>
>> Christer
>>
>>
>> -Original Message-
>> From: Christer Holmberg [mailto:christer.holmb...@ericsson.com]
>> Sent: 07 August 2016 20:13
>> To: Brian E Carpenter <brian.e.carpen...@gmail.com>; 
>> draft-ietf-clue-datachannel@ietf.org; General Area Review Team 
>> <gen-art@ietf.org>
>> Subject: RE: Gen-ART Last Call review of 
>> draft-ietf-clue-datachannel-13
>>
>> Hi Brian,
>>
>> ...
>>
>>>>> Minor issues:
>>>>> -
>>>>>
>>>>> Mainly for my own education:
>>>>>
>>>>> 3.2.6.  SCTP Multihoming
>>>>>
>>>>>  SCTP multi-homing is not supported for SCTPoDTLS associations, and  
>>>>> can therefore not be used for a CLUE data channel.
>>>>>
>>>>> What is the advantage of SCTP if you don't get the benefit of multihoming?
>>>>
>>>> There are other SCTP features that are used. The most essential is 
>>>> the SCTP multi stream feature, which allows multiple data channels 
>>>> using a single SCTP associations: each data channel is implemented using 
>>>> two unidirectional SCTP streams.
>>>>
>>>> SCTP also provide different options when it comes to data transport 
>>>> reliability and ordering, and data channels can use different combinations.
>>>
>>> OK, thanks. I have the impression that this explanation is given 
>>> nowhere in the CLUE documents (and not in draft-ietf-rtcweb-transports 
>>> either). I think it would be helpful if it was recorded *somewhere*.
>>> It doesn't really belong in clue-datachannel.
>>
>> I agree - it's not the task of CLUE to justify the decisions made by RTCWEB.
>>
>> For the details of the data channel mechanism, please take a look at 
>> draft-ietf-rtcweb-data-channel.
>>
>> https://tools.ietf.org/html/draft-ietf-rtcweb-data-channel
>>
>> Regards,
>>
>> Christer
>>
>>
>>
>>>
>>>
>>>> Nits:
>>>> -
>>>>
>>>> I expected a reference to draft-ietf-clue-protocol where CLUE is first 
>>>> mentioned in the Introduction.
>>>
>>> I'll fix that.
>>
>> Thanks
>>Brian
> 
> 

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

Re: [Gen-art] Gen-ART Last Call review of draft-ietf-ospf-two-part-metric-05

[Brian E Carpenter]

Hi,

That's all good. With the clarifcations, I think the "Updates" is OK too.
I still don't think you need the pre-2008 disclaimer, but that's a nit.

Thanks
   Brian

On 09/08/2016 09:27, Jeffrey (Zhaohui) Zhang wrote:
> Please see -07 version that should address the issues raised by Brian (except 
> that "update" part).
> 
> https://tools.ietf.org/html/draft-ietf-ospf-two-part-metric-07
> 
> Thanks.
> Jeffrey
> 
>> -Original Message-
>> From: Acee Lindem (acee) [mailto:a...@cisco.com]
>> Sent: Monday, August 08, 2016 5:02 PM
>> To: Brian E Carpenter <brian.e.carpen...@gmail.com>; draft-ietf-ospf-two-
>> part-metric@ietf.org; General Area Review Team <gen-art@ietf.org>
>> Subject: Re: Gen-ART Last Call review of draft-ietf-ospf-two-part-metric-
>> 05
>>
>> Hi Brian,
>>
>> See one inline.
>>
>> On 8/8/16, 4:18 PM, "Brian E Carpenter" <brian.e.carpen...@gmail.com>
>> wrote:
>>
>>> Hi Acee,
>>>
>>> Thanks, just a few points in line:
>>>
>>> On 09/08/2016 05:47, Acee Lindem (acee) wrote:
>>>> Hi Brian,
>>>>
>>>> Thanks much for the thorough review. Jeffrey and I discussed your
>>>> comments
>>>> this morning. See responses to your major/minor comments below. We will
>>>> incorporate all the nits.
>>>>
>>>> On 8/6/16, 9:38 PM, "Brian E Carpenter" <brian.e.carpen...@gmail.com>
>>>> 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
>>>>> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
>>>>>
>>>>> Document: draft-ietf-ospf-two-part-metric-05.txt
>>>>> Reviewer: Brian Carpenter
>>>>> Review Date: 2016-08-07
>>>>> IETF LC End Date: 2016-08-15
>>>>> IESG Telechat date:
>>>>>
>>>>> Summary: Almost ready
>>>>> 
>>>>>
>>>>> Major issues:
>>>>> -
>>>>>
>>>>>> Updates: 2328, 5340 (if approved)
>>>>>
>>>>> If that is so, the text needs to explain what is changed in those two
>>>>> RFCs. Since
>>>>> this draft describes an "optional extension" to OSPF, it does not
>>>>> obviously update
>>>>> them. Is any text in those two RFCs made invalid by this draft?
>>>>
>>>> This has been an ongoing debate as to whether an RFC the augments an
>>>> existing draft updates it or whether it must actually change the
>>>> existing
>>>> behavior. In this case, the SPF calculation is modified as specified in
>>>> section 3.6 but only when the new Network-to-Router metric is
>>>> advertised.
>>>> In RFC 2328 and RFC 5340, this cost is always zero (i.e., cost to reach
>>>> all routers connected to the network is solely the outgoing metric
>>>> metric
>>>> or Router-to-Network metric).
>>>
>>> OK, fair comment.
>>>
>>>>
>>>> I, for one, would be very happy to have consensus of precisely what
>>>> constitutes update to an existing RFC.
>>>
>>> So would many people, and since it affects all RFC streams, not just the
>>> IETF stream, I happen to know that the RFC Editor is working on
>>> definitions
>>> for both "updates" and "obsoletes".
>>>
>>>> If we don’t update the existing
>>>> RFCs, we would avoid the pre-2008 IPR language.
>>>
>>> That doesn't seem right. You only need that language if you are updating
>>> whole chunks of older text. If you take a paragraph from a pre-2008
>>> document,
>>> change a few words, and patch it into the new document, you need either
>>> the agreement of the original authors or the pre-2008 disclaimer. But I
>>> don't think you're doing that in this case, are you?
>>
>> No. We are simply using the context of the existing SPF calculation to
>> describe the additional function.
>>
>> Thanks,
>> Acee
>>
>>
>>
>>
>>>
>>

Re: [Gen-art] Gen-ART Last Call review of draft-ietf-ospf-two-part-metric-05

[Brian E Carpenter]

Hi Acee,

Thanks, just a few points in line:

On 09/08/2016 05:47, Acee Lindem (acee) wrote:
> Hi Brian, 
> 
> Thanks much for the thorough review. Jeffrey and I discussed your comments
> this morning. See responses to your major/minor comments below. We will
> incorporate all the nits.
> 
> On 8/6/16, 9:38 PM, "Brian E Carpenter" <brian.e.carpen...@gmail.com>
> 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
>> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
>>
>> Document: draft-ietf-ospf-two-part-metric-05.txt
>> Reviewer: Brian Carpenter
>> Review Date: 2016-08-07
>> IETF LC End Date: 2016-08-15
>> IESG Telechat date:
>>
>> Summary: Almost ready
>> 
>>
>> Major issues:
>> -
>>
>>> Updates: 2328, 5340 (if approved)
>>
>> If that is so, the text needs to explain what is changed in those two
>> RFCs. Since
>> this draft describes an "optional extension" to OSPF, it does not
>> obviously update
>> them. Is any text in those two RFCs made invalid by this draft?
> 
> This has been an ongoing debate as to whether an RFC the augments an
> existing draft updates it or whether it must actually change the existing
> behavior. In this case, the SPF calculation is modified as specified in
> section 3.6 but only when the new Network-to-Router metric is advertised.
> In RFC 2328 and RFC 5340, this cost is always zero (i.e., cost to reach
> all routers connected to the network is solely the outgoing metric metric
> or Router-to-Network metric).

OK, fair comment.

> 
> I, for one, would be very happy to have consensus of precisely what
> constitutes update to an existing RFC. 

So would many people, and since it affects all RFC streams, not just the
IETF stream, I happen to know that the RFC Editor is working on definitions
for both "updates" and "obsoletes".

> If we don’t update the existing
> RFCs, we would avoid the pre-2008 IPR language.

That doesn't seem right. You only need that language if you are updating
whole chunks of older text. If you take a paragraph from a pre-2008 document,
change a few words, and patch it into the new document, you need either
the agreement of the original authors or the pre-2008 disclaimer. But I
don't think you're doing that in this case, are you?

>>> 3.6.  SPF Calculation
>>>
>>>   During the first stage of shortest-path tree calculation for an area,
>>>   when a vertex V corresponding to a Network-LSA is added to the
>>>   shortest-path tree and its adjacent vertex W (joined by a link in V's
>>>   corresponding Network LSA), the cost from V to W, which is W's
>>>   network-to-router cost, is determined as follows:
>>
>> I can't parse that sentence. If we delete the subordinate clauses, we get
>>
>>  When a vertex V is added to the shortest-path tree and its adjacent
>> vertex W,
>>  the cost from V to W is determined as follows:
>>
>> What does that mean? What does "its" refer to? Is W adjacent to V, or is
>> W adjacent
>> to the existing tree? Is W added to the tree before V, or is V added
>> before W?
>> If I was coding this, I'd have no idea what to do.
> 
> You really do have to look at RFC 2328 to understand it. 

Yes, I did that in some detail when I was teaching routing a few years ago ;-)

> Does this
> modified text parse better?
> 
> The first stage of the shortest-path tree calculation is described
> in section 16.1 of [RFC 2328] and modified for OSPFv3 as described in
> section 4.8.1 of [RFC 5340]. When a vertex V corresponding to a
> Network-LSA
> has just been added to the Shortest Path Tree (SPT) and an adjacent
> vertex W 
> (joined by a link in V’s corresponding Network-LSA) is being added to
> the SPT, the cost from V to W (W’s network-to-router cost) is
> determined 
> as follows:

MUCH better. It also clarifies the "Updates:" aspect.

Thanks
   Brian

> 
>>
>>> 3.7.  Backward Compatibility
>>
>> This calls for a Router Functional Capability Bit assignment under RFC
>> 7770.
>> The bit number should be given as (say) TBD1 not as 0.
>>
>>> 4.  IANA Considerations
>>
>> The IANA considerations ask for four assignments. These should be
>> specified as TBD1,
>> TBD2, TBD3, TBD4 and the TBDs

[Gen-art] Gen-ART Last Call review of draft-ietf-ospf-two-part-metric-05

[Brian E Carpenter]

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-ospf-two-part-metric-05.txt
Reviewer: Brian Carpenter
Review Date: 2016-08-07
IETF LC End Date: 2016-08-15
IESG Telechat date:

Summary: Almost ready


Major issues:
-

> Updates: 2328, 5340 (if approved)

If that is so, the text needs to explain what is changed in those two RFCs. 
Since
this draft describes an "optional extension" to OSPF, it does not obviously 
update
them. Is any text in those two RFCs made invalid by this draft?

> 3.6.  SPF Calculation
>
>   During the first stage of shortest-path tree calculation for an area,
>   when a vertex V corresponding to a Network-LSA is added to the
>   shortest-path tree and its adjacent vertex W (joined by a link in V's
>   corresponding Network LSA), the cost from V to W, which is W's
>   network-to-router cost, is determined as follows:

I can't parse that sentence. If we delete the subordinate clauses, we get

  When a vertex V is added to the shortest-path tree and its adjacent vertex W,
  the cost from V to W is determined as follows:

What does that mean? What does "its" refer to? Is W adjacent to V, or is W 
adjacent
to the existing tree? Is W added to the tree before V, or is V added before W?
If I was coding this, I'd have no idea what to do.

> 3.7.  Backward Compatibility

This calls for a Router Functional Capability Bit assignment under RFC 7770.
The bit number should be given as (say) TBD1 not as 0.

> 4.  IANA Considerations

The IANA considerations ask for four assignments. These should be specified as 
TBD1,
TBD2, TBD3, TBD4 and the TBDs elsewhere in the text should be updated 
correspondingly.
Also, please reference the relevant RFCs (7770 and whatever defines the Sub-TLV 
registries.)

Finally, to put this on the standards track, I would really expect to see
an Implementation Status section (RFC 7942). Has this been tested?

Minor issues:
-

Please check the three occurrences of lower-case "must" in Section 3. Should 
they be "MUST"?

> 5.  Security Considerations
>
>   This document does not introduce new security risks.

That's easy to say but hard to prove. Shouldn't you at least refer to the 
security
considerations of OSPFv2 and OSPFv3?

Also, does section 3.7 introduce a new risk whereby a rogue router could flap 
its
Two-Part Metric bit on and off, causing all its OSPF peers to continually 
recalculate
their routes?

Nits:
-

> Requirements Language

It's unusual to put this at the front. The normal place is after the 
Introduction.

>  This document may contain material from IETF Documents or IETF
>  Contributions published or made publicly available before November
>  10, 2008. ...

Why is this needed? What did you copy from an old document?

> 0 OSPF Two-part Metric [TPM]

The abbreviation TPM is defined but not used, so why bother? Also, 
s/[TPM]/(TPM)/ to
avoid confusion with a reference.

> routes w/o considering any network-to-router costs.

Just say "without".

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

Re: [Gen-art] Gen-ART Last Call review of draft-ietf-clue-datachannel-13

[Brian E Carpenter]

On 02/08/2016 09:47, Christer Holmberg wrote:
> Hi Brian,
> 
> Thanks for your review! Please see inline.
> 
>> 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-clue-datachannel-13.txt
>> Reviewer: Brian Carpenter
>> Review Date: 2016-07-28
>> IETF LC End Date: 2016-08-01
>> IESG Telechat date:
>>
>> Summary: Ready
>> 
>>
>> Minor issues:
>> -
>>
>> Mainly for my own education:
>>
>> 3.2.6.  SCTP Multihoming
>>
>>   SCTP multi-homing is not supported for SCTPoDTLS associations, and
>>   can therefore not be used for a CLUE data channel.
>>
>> What is the advantage of SCTP if you don't get the benefit of multihoming?
> 
> There are other SCTP features that are used. The most essential is the SCTP 
> multi stream feature, which allows multiple data channels using a single SCTP 
> associations: each data channel is implemented using two unidirectional SCTP 
> streams.
> 
> SCTP also provide different options when it comes to data transport 
> reliability and ordering, and data channels can use different combinations.

OK, thanks. I have the impression that this explanation is given nowhere in the 
CLUE
documents (and not in draft-ietf-rtcweb-transports either). I think it would be
helpful if it was recorded *somewhere*. It doesn't really belong in 
clue-datachannel.

> 
> 
>> Nits:
>> -
>>
>> I expected a reference to draft-ietf-clue-protocol where CLUE is first 
>> mentioned in the Introduction.
> 
> I'll fix that.

Thanks
Brian

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

[Gen-art] Gen-ART Last Call review of draft-ietf-clue-datachannel-13

[Brian E Carpenter]

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-clue-datachannel-13.txt
Reviewer: Brian Carpenter
Review Date: 2016-07-28
IETF LC End Date: 2016-08-01
IESG Telechat date:

Summary: Ready


Minor issues:
-

Mainly for my own education:

3.2.6.  SCTP Multihoming

   SCTP multi-homing is not supported for SCTPoDTLS associations, and
   can therefore not be used for a CLUE data channel.

What is the advantage of SCTP if you don't get the benefit of multihoming?

Nits:
-

I expected a reference to draft-ietf-clue-protocol where CLUE is first mentioned
in the Introduction.

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

Re: [Gen-art] Gen-ART Last Call review of draft-ietf-nfsv4-multi-domain-fs-reqs-09

[Brian E Carpenter]

Hi,

So we have this in the minutes:

> Get status - is it in WG last call. Should it be informational
> or standards draft. Draft clarifies how make all this work.

...i.e. it describes best practice, not protocol details.

> 
> 2119 MUSTs, SHOULDs and MAYs can be used in an informational draft
> says David Black. 

They can, but they are a clear signal to think carefully.

> Martin thinks its wise to put on standards track.

In the end it's a judgment call, of course, but "make this all work"
is surely the goal of most BCPs?

Regards
Brian




Regards
   Brian Carpenter
   http://orcid.org/-0001-7924-6182



On 12/07/2016 02:47, Adamson, Andy wrote:
> 
>> On Jul 5, 2016, at 11:54 AM, Brian E Carpenter <brian.e.carpen...@gmail.com> 
>> 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
>> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
>>
>> Document: draft-ietf-nfsv4-multi-domain-fs-reqs-09.txt
>> Reviewer: Brian Carpenter
>> Review Date: 2016-07-05
>> IETF LC End Date: 2016-07-06
>> IESG Telechat date:
>>
>> Summary: Ready with issues
>> 
>>
>> Comment: I was asked to review -08 but found -09 has been posted, with
>>  considerable changes, during Last Call.
>>
>>
>> Minor issues:
>> -
>>
>> "This document provides guidance on the deployment of..."
>>
>> Sounds more like a BCP than a Proposed Standard to me.
> 
> 
> Hi Brian
> 
> The “Informational vrs Standards” track issue was discussed at IETF93. From 
> the minutes at https://datatracker.ietf.org/doc/minutes-93-nfsv4/
> 
> -- Multidomain draft (Adamson)
> 
> No slides.
> 
> Similar to layout types. Clarifying issues in NFS V4.0 and 4.1,
> especially with FedFS.
> 
> Get status - is it in WG last call. Should it be informational
> or standards draft. Draft clarifies how make all this work.
> 
> 2119 MUSTs, SHOULDs and MAYs can be used in an informational draft
> says David Black. Martin thinks its wise to put on standards track.
> No errata to speak of - just additional information.
> 
> 
> 
>>  As I read through the
>> document, it describes alternatives and differing scenarios. That also seems
>> like BCP to me. One example:
>>
>>> 7.  Resolving Multi-domain Authorization Information
>>>
>>>  When an RPCSEC_GSS principal is seeking access to files on an NFSv4
>>>  server, after authenticating the principal, the server must obtain in
>>>  a secure manner the principal's authorization context information
>>>  from an authoritative source such as the name service in the
>>>  principal's NFSv4 Domain.
>>
>> That's underspecified for a standard but perfect for a description of
>> best practice.
> 
> I propose to change the above ‘must’ to a ’SHOULD’. The above actually 
> applies to an NFSv4 server using RPCSEC_GSS in any environment as it does no 
> good (e.g. it is insecure) to establish the authentication of a principal in 
> a secure manner, and to then map that principal to local file system 
> representation authorization info for file access determination in an 
> insecure manner.
> 
> I thought this was specified in previous standards - but I can’t find mention 
> of any requirement for security in gathering  authorization information on an 
> RPCSEC_GSS authenticated principal anywhere in RFC7530, RFC5661 nor in the 
> FedFS RFC’s. Section 5.9 of RFC 7530 discusses the translation of security 
> principals into " a common format, generally that used by local storage, to 
> serve as a means of identifying the users corresponding to these security 
> principals.”  but makes no mention of requiring a secure translation method.
> 
> The only mention I find is in the Security Considerations section of 
> draft-cel-nfsv4-federated-fs-security-addendum-05 which states:
> 
> "When deploying FedFS, the use of security mechanisms that maintain
>the confidentiality of all network communications is recommended."
> 
>>
>> The choices between lower-case and upper-case "must" seem fairly arbitrary.
>> There are only 5 instances of "MUST" and one "REQUIRED". Maybe this document 
>> just
>> doesn't need RFC2119 keywords?
> 
> The doc definitely needs RFC2119 ke

Re: [Gen-art] A *new* batch of IETF LC reviews - 2016-07-08

[Brian E Carpenter]

Last Calls ending in the middle of an IETF week?

Hate to say this, but my review is not going to happen on that timescale.
I thought that the IESG policy was never to issue Last Calls on top of
an IETF week.

Brian

On 09/07/2016 07:47, A. Jean Mahoney wrote:
> Hi all,
> 
> The following reviewers have assignments:
> 
> Reviewer  LC end  Draft
> -
> Brian Carpenter   2016-07-21  draft-ietf-clue-datachannel-13
> 
> Christer Holmberg 2016-07-21
>draft-ietf-xrblock-independent-burst-gap-discard-02
> 
> Wassim Haddad *   2016-07-21  draft-ietf-rtcweb-transports-14
> 
> 
> 
> I have made the assignments in the review tool:
> http://art.tools.ietf.org/tools/art/genart/
> 
> And the assignments are captured in the spreadsheets:
> http://wiki.tools.ietf.org/dav/genart/gen-art.html
> http://wiki.tools.ietf.org/dav/genart/gen-art-by-reviewer.html
> 
> The updated template is included below.
> 
> Thanks,
> 
> Jean
> 
> ---
> 
> 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:
> Reviewer:
> Review Date:
> IETF LC End Date:
> IESG Telechat date: (if known)
> 
> Summary:
> 
> Major issues:
> 
> Minor issues:
> 
> Nits/editorial comments:
> 
> ___
> Gen-art mailing list
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art
> 

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

[Gen-art] Gen-ART Last Call review of draft-ietf-nfsv4-multi-domain-fs-reqs-09

[Brian E Carpenter]

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-nfsv4-multi-domain-fs-reqs-09.txt
Reviewer: Brian Carpenter
Review Date: 2016-07-05
IETF LC End Date: 2016-07-06
IESG Telechat date:

Summary: Ready with issues


Comment: I was asked to review -08 but found -09 has been posted, with
 considerable changes, during Last Call.


Minor issues:
-

"This document provides guidance on the deployment of..."

Sounds more like a BCP than a Proposed Standard to me. As I read through the
document, it describes alternatives and differing scenarios. That also seems
like BCP to me. One example:

> 7.  Resolving Multi-domain Authorization Information
>
>   When an RPCSEC_GSS principal is seeking access to files on an NFSv4
>   server, after authenticating the principal, the server must obtain in
>   a secure manner the principal's authorization context information
>   from an authoritative source such as the name service in the
>   principal's NFSv4 Domain.

That's underspecified for a standard but perfect for a description of
best practice.

The choices between lower-case and upper-case "must" seem fairly arbitrary.
There are only 5 instances of "MUST" and one "REQUIRED". Maybe this document 
just
doesn't need RFC2119 keywords?

  ** Downref: Normative reference to an Informational RFC: RFC 1813

This reference was added in the -09 version. I believe it should be
Informative instead of Normative. If not, a new Last Call mentioning
the downref is necessary.

  ** Obsolete normative reference: RFC 1831 (Obsoleted by RFC 5531)

This needs to be fixed.

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

[Gen-art] Gen-ART telechat review of draft-ietf-alto-deployments-15

[Brian E Carpenter]

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-alto-deployments-15.txt
Reviewer: Brian Carpenter
Review Date: 2016-06-13
IETF LC End Date: 2016-06-21
IESG Telechat date: 2016-06-30

Summary: Ready


Comment:


This is a long document but well written, so there is little to say about it.

Minor issues:
-

The Conclusion section could be deleted. It doesn't add anything.

There are a lot of Informational references that are still personal I-Ds. Many 
of
them are not even listed as "Related Internet-Drafts" for the Alto WG. I think 
readers
of the future RFC will find this a bit annoying.

Nits:
-

 and  bounced

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

[Gen-art] Gen-ART Last Call review of draft-ietf-alto-deployments-15

[Brian E Carpenter]

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-alto-deployments-15.txt
Reviewer: Brian Carpenter
Review Date: 2016-06-13
IETF LC End Date: 2016-06-21
IESG Telechat date: 2016-06-30

Summary: Ready


Comment:


This is a long document but well written, so there is little to say about it.

Minor issues:
-

The Conclusion section could be deleted. It doesn't add anything.

There are a lot of Informational references that are still personal I-Ds. Many 
of
them are not even listed as "Related Internet-Drafts" for the Alto WG. I think 
readers
of the future RFC will find this a bit annoying.

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

Re: [Gen-art] I-D Action: draft-ietf-teas-interconnected-te-info-exchange-07.txt

[Brian E Carpenter]

Thank you for the latest changes. I think they clarify things very well.

Regards
   Brian Carpenter

On 22/05/2016 00:22, internet-dra...@ietf.org wrote:
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Traffic Engineering Architecture and 
> Signaling of the IETF.
> 
> Title   : Problem Statement and Architecture for Information 
> Exchange Between Interconnected Traffic Engineered Networks
> Authors : Adrian Farrel
>   John Drake
>   Nabil Bitar
>   George Swallow
>   Daniele Ceccarelli
>   Xian Zhang
>   Filename: draft-ietf-teas-interconnected-te-info-exchange-07.txt
>   Pages   : 61
>   Date: 2016-05-21
> 
> Abstract:
>In Traffic Engineered (TE) systems, it is sometimes desirable to
>establish an end-to-end TE path with a set of constraints (such as
>bandwidth) across one or more network from a source to a destination.
>TE information is the data relating to nodes and TE links that is
>used in the process of selecting a TE path.  TE information is
>usually only available within a network.  We call such a zone of
>visibility of TE information a domain. An example of a domain may be
>an IGP area or an Autonomous System.
> 
>In order to determine the potential to establish a TE path through a
>series of connected networks, it is necessary to have available a
>certain amount of TE information about each network.  This need not
>be the full set of TE information available within each network, but
>does need to express the potential of providing TE connectivity. This
>subset of TE information is called TE reachability information.
> 
>This document sets out the problem statement for the exchange of TE
>information between interconnected TE networks in support of end-to-
>end TE path establishment and describes the best current practice
>architecture to meet this problem statement.  For reasons that are
>explained in the document, this work is limited to simple TE
>constraints and information that determine TE reachability.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-teas-interconnected-te-info-exchange/
> 
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-teas-interconnected-te-info-exchange-07
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-teas-interconnected-te-info-exchange-07
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> ___
> I-D-Announce mailing list
> i-d-annou...@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 

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