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

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:
> 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”).
> 
> 
> 
> _______________________________________________
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring
> 