Subject: [spring] Barry Leiba's No Objection on draft-ietf-spring-srv6-network-programming-19: (with COMMENT)

From: Barry Leiba via Datatracker <[email-masked]>
Date: Mon, 21 Sep 2020 10:17:12 -0700

Barry Leiba has entered the following ballot position for
draft-ietf-spring-srv6-network-programming-19: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-spring-srv6-network-programming/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Throughout the document:
It should be “an SID”, “an FIB”, “an RIR”, and some others, not “a”, because
one reads these as “ess-eye-dee” and “eff-eye-bee”, not as the expansions
thereof.

— Section 3.1 —

   An SRv6 endpoint behavior MAY require additional information

I think this is a statement of fact, so “may” (or “might”), not “MAY”.

— Section 3.2 —
Nit: The plural of “SID” is “SIDs”, without an apostrophe.

   The provider historically deployed IPv6 and assigned
   infrastructure address from a portion of the fc00::/7 prefix

Nit: “addresses”.

   In another example, a large mobile and fixed line service provider

Nit: hyphenate “fixed-line”.

   IPv6 address consumption in both these examples is minimum,

Nit: “minimal” (also, put a comma before “respectively”).

   A remote node uses the IANA behavior codepoint to map the received
   SID (B:N:FUNCT) to a behavior.

I don’t know what “IANA behavior codepoint” means.  As the rest of the sentence
makes it clear that this is mapping to “a behavior”, maybe it’s better to say
“registered codepoint”, or some such?  Or, as you say a couple of paragraphs
down, “Endpoint Behavior codepoint”?  In any case, please be consistent about
“IANA behavior”, “IANA Behavior”, and “IANA Endpoint Behavior”.  My preference
would be to avoid saying “IANA” in these, but use your judgment on what’s most
understandable and clear.

   o  Assign an SRv6 Locator 2001:db8:bbbb:3::/64 to the Router 3 in
      their SR Domain

What is “the Router 3” (and router 4)?  There’s no introduction nor diagram
that says.  Also, please be consistent in capitalization of these.

— Section 3.3 —

   routing protocol specific aspects that are outside the scope of this

Nit: “routing-protocol-specific” needs to be hyphenated.  As that’s awkward,
you might want to reword to avoid it, “are specific to the routing protocol and
are outside the scope....”

— Section 4 —

   The pseudocode describing these behaviors detail local processing

Nit: “details”, singular, to match “pseudocode”.

— Section 4.1 —

   The End behavior operates on the same FIB table (i.e.  VRF, L3 relay
   id) associated to the packet.

Is “i.e.” really what you want here?  How does “VRF, L3 relay” equate to “FIB
table”?

— Section 4.16.1.3 —

   segments left to 0.  The SDN controller knows that no-other node

Nit: “no other” should not be hyphenated.  For that matter, the word “other”
isn’t needed anyway, because you have “after” in there.

   -as part of the decapsulation process the egress PE is required to
    terminates less bytes from the packet.

I can’t figure this out.  It looks like it should be “required to terminate”,
but I don’t know what it means to “terminate less bytes”.  Can you reword this?

    to the lookup engine in the forwarding ASIC.

“ASIC” needs to be expanded.  As this is the only place you use it, I suggest
just using the expansion and not bothering with the abbreviation.

— Section 7 —

   This document introduces SRv6 Endpoint and SR Policy Headend
   behaviors for implementation on SRv6 capable nodes in the network.
   As such, this document does not introduce any new security
   considerations.

I’m not convinced of this.  It seems that misuse (such as injection or
alteration) of some of these Behaviors could, for example, result in packets
being forwarded to nodes they were not intended to go to.  Is it not important
to discuss issues such as that: how these Behaviors might be attacked?  Is that
really fully covered in 8754 and 8402?

— Section 8.1 —

   The presence of SIDs in the IGP do not imply any routing semantics

Nit: “does not”, to match the singular subject “the presence”.

   an IPv6 address is solely governed by the, non-SID-related, IGP

Nit: remove both commas.

   not governed neither influenced in any way by a SID advertisement

Nit: make it “neither governed nor influenced”

   build TI-LFA [I-D.ietf-rtgwg-segment-routing-ti-lfa] based FRR
   solutions

Nit: there needs to be a hyphen in there, but the citation gets in the way. 
Make it, “build FRR solutions based on TI-LFA
[I-D.ietf-rtgwg-segment-routing-ti-lfa]”.

— Section 8.4 —

   For example, a BGP-LS advertisement of H.Encaps behavior would
   describe the capability of node N to perform a H.Encaps behavior,
   specifically it would describe how many SIDs could be pushed by N
   without significant performance degradation.

This is a comma splice.  Split the sentence before “specifically” (and put a
comma after “specifically”).

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 21 Sep 2020 13:45:03 -0400

Actually Barry, I would liek to leave the article choice to the RPC.  In 
my experience, one does pronounce SID and FIB as words, but RIR as the 
letters.

Yours,
Joel

On 9/21/2020 1:17 PM, Barry Leiba via Datatracker wrote:
> _______________________________________________
> spring mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spring
>

---

From: "Pablo Camarillo (pcamaril)" <[email-masked]>
Date: Tue, 22 Sep 2020 20:00:34 +0000

Hi Barry,

Many thanks for your review. See inline with [PC].

Regards,
Pablo.

-----Original Message-----
From: Barry Leiba via Datatracker <[email-masked]> 
Sent: lunes, 21 de septiembre de 2020 19:17
To: The IESG <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; Bruno Decraene <[email-masked]>; Joel Halpern <[email-masked]>; [email-masked]
Subject: Barry Leiba's No Objection on draft-ietf-spring-srv6-network-programming-19: (with COMMENT)

When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.)

Throughout the document:
It should be “an SID”, “an FIB”, “an RIR”, and some others, not “a”, because one reads these as “ess-eye-dee” and “eff-eye-bee”, not as the expansions thereof.
[PC] Agreed for RIR. For the other ones I’ve seen some disagreement on this regard in between native English speakers. I’m not a native English speaker, hence I would prefer to leave the decision up to RFC Editor.

— Section 3.1 —

I think this is a statement of fact, so “may” (or “might”), not “MAY”.
[PC] Ack. Fixed for next rev.

— Section 3.2 —
Nit: The plural of “SID” is “SIDs”, without an apostrophe.
[PC] Ack. Fixed for next rev.

Nit: “addresses”.
[PC] Ack. Fixed for next rev.

Nit: hyphenate “fixed-line”.
[PC] Ack. Fixed for next rev.

Nit: “minimal” (also, put a comma before “respectively”).
[PC] Ack. Fixed for next rev.

I don’t know what “IANA behavior codepoint” means.  As the rest of the sentence makes it clear that this is mapping to “a behavior”, maybe it’s better to say “registered codepoint”, or some such?  Or, as you say a couple of paragraphs down, “Endpoint Behavior codepoint”?  In any case, please be consistent about “IANA behavior”, “IANA Behavior”, and “IANA Endpoint Behavior”.  My preference would be to avoid saying “IANA” in these, but use your judgment on what’s most understandable and clear.
[PC] Indeed. I will change all references to Endpoint Behavior codepoint.

What is “the Router 3” (and router 4)?  There’s no introduction nor diagram that says.  Also, please be consistent in capitalization of these.
[PC] Ack. Fixed for next rev.

— Section 3.3 —

Nit: “routing-protocol-specific” needs to be hyphenated.  As that’s awkward, you might want to reword to avoid it, “are specific to the routing protocol and are outside the scope....”
[PC] Reworded is better indeed.

— Section 4 —

Nit: “details”, singular, to match “pseudocode”.
[PC] Ack. Fixed for next rev.

— Section 4.1 —

Is “i.e.” really what you want here?  How does “VRF, L3 relay” equate to “FIB table”?
[PC] Indeed. The corrected parenthesis should be: (i.e. identified by VRF or L3 relay id)

— Section 4.16.1.3 —

Nit: “no other” should not be hyphenated.  For that matter, the word “other”
isn’t needed anyway, because you have “after” in there.
[PC] Ack. Fixed for next rev.

I can’t figure this out.  It looks like it should be “required to terminate”, but I don’t know what it means to “terminate less bytes”.  Can you reword this?
[PC] I propose the following diff:
<OLD>
as part of the decapsulation process the egress PE is required to terminates less bytes from the packet.
</OLD>
<NEW>
as part of the decapsulation process the egress PE is required to parse and remove fewer bytes from the packet.
</NEW>

“ASIC” needs to be expanded.  As this is the only place you use it, I suggest just using the expansion and not bothering with the abbreviation.
[PC] Ack. Fixed for next rev.

— Section 7 —

I’m not convinced of this.  It seems that misuse (such as injection or
alteration) of some of these Behaviors could, for example, result in packets being forwarded to nodes they were not intended to go to.  Is it not important to discuss issues such as that: how these Behaviors might be attacked?  Is that really fully covered in 8754 and 8402?

[PC] You mention injection alteration or misuse of these behaviors, the paragraph preceding the one you quote in revision 19 states:
“Additionally, [RFC8754] defines an HMAC TLV permitting SR
   Endpoint Nodes in the SR domain to verify that the SRH applied to a
   packet was selected by an authorized party and to ensure that the
   segment list is not modified after generation, regardless of the
   number of segments in the segment list.”

This text was added to revision 19 as part of the SECDIR review, and I think this provides a reminder of how misuse or alteration within the SR domain of trust can be handled based on RFC8754. Can you please check if this addresses your comment?

— Section 8.1 —

Nit: “does not”, to match the singular subject “the presence”.
[PC] Ack. Fixed for next rev.

Nit: remove both commas.
[PC] Ack. Fixed for next rev.

Nit: make it “neither governed nor influenced”
[PC] Ack. Fixed for next rev.

Nit: there needs to be a hyphen in there, but the citation gets in the way. 
Make it, “build FRR solutions based on TI-LFA [I-D.ietf-rtgwg-segment-routing-ti-lfa]”.
[PC] Better. Thanks

— Section 8.4 —

This is a comma splice.  Split the sentence before “specifically” (and put a comma after “specifically”).
[PC] Ack. Fixed for next rev.

---

From: Barry Leiba <[email-masked]>
Date: Tue, 22 Sep 2020 17:04:40 -0400

Thanks for the reply, Pablo (and thanks also to Joel for his reply).
All good here.  And just confirming three items in particular:

>> It should be “an SID”, “an FIB”, “an RIR”, and some others, not “a”, because one reads these as
>> “ess-eye-dee” and “eff-eye-bee”, not as the expansions thereof.
>
> [PC] Agreed for RIR. For the other ones I’ve seen some disagreement on this regard in between
> native English speakers. I’m not a native English speaker, hence I would prefer to leave the decision
> up to RFC Editor.

As Joel said also, and I agree.

>> I can’t figure this out.  It looks like it should be “required to terminate”, but I don’t know what it means
> to “terminate less bytes”.  Can you reword this?
>

A very fine change; thanks.

>> I’m not convinced of this.  It seems that misuse (such as injection or alteration) of some of these Behaviors could,
>> for example, result in packets being forwarded to nodes they were not intended to go to.  Is it not important to
>> discuss issues such as that: how these Behaviors might be attacked?  Is that really fully covered in 8754 and 8402?
>
> This text was added to revision 19 as part of the SECDIR review, and I think this provides a reminder of how misuse
> or alteration within the SR domain of trust can be handled based on RFC8754. Can you please check if this addresses
> your comment?

It does, and thanks for pointing it out.  I think I must have had that
comment left over from an earlier start on reviewing, and hadn't
double-checked it with the latest version.

Barry

---

From: "Pablo Camarillo (pcamaril)" <[email-masked]>
Date: Wed, 23 Sep 2020 16:27:49 +0000

Barry, 

Many thanks for the confirmation of those three points.
We have posted an updated version of the I-D with all the changes discussed below.

Regards,
Pablo.

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-20
https://datatracker.ietf.org/doc/html/draft-ietf-spring-srv6-network-programming-20

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-spring-srv6-network-programming-20

-----Original Message-----
From: Barry Leiba <[email-masked]> 
Sent: martes, 22 de septiembre de 2020 23:05
To: Pablo Camarillo (pcamaril) <[email-masked]>
Cc: The IESG <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; Bruno Decraene <[email-masked]>; Joel Halpern <[email-masked]>
Subject: Re: Barry Leiba's No Objection on draft-ietf-spring-srv6-network-programming-19: (with COMMENT)

Thanks for the reply, Pablo (and thanks also to Joel for his reply).
All good here.  And just confirming three items in particular:

>> It should be “an SID”, “an FIB”, “an RIR”, and some others, not “a”, 
>> because one reads these as “ess-eye-dee” and “eff-eye-bee”, not as the expansions thereof.
>
> [PC] Agreed for RIR. For the other ones I’ve seen some disagreement on 
> this regard in between native English speakers. I’m not a native 
> English speaker, hence I would prefer to leave the decision up to RFC Editor.

>> I can’t figure this out.  It looks like it should be “required to 
>> terminate”, but I don’t know what it means

>> I’m not convinced of this.  It seems that misuse (such as injection 
>> or alteration) of some of these Behaviors could, for example, result 
>> in packets being forwarded to nodes they were not intended to go to.  Is it not important to discuss issues such as that: how these Behaviors might be attacked?  Is that really fully covered in 8754 and 8402?
>
> [PC] You mention injection alteration or misuse of these behaviors, 
> the paragraph preceding the one you quote in revision 19 states:
> This text was added to revision 19 as part of the SECDIR review, and I 
> think this provides a reminder of how misuse or alteration within the 
> SR domain of trust can be handled based on RFC8754. Can you please check if this addresses your comment?

It does, and thanks for pointing it out.  I think I must have had that comment left over from an earlier start on reviewing, and hadn't double-checked it with the latest version.

Barry