Re: [MBONED] WGLC for draft-ietf-mboned-dc-deploy and draft-ietf-mboned-deprecate-interdomain-asm

[Leonard Giuliano <[e-mail]>]

Jake- thanks for the thorough review.  We are discussing the changes and 
will get back to you shortly.


On Wed, 7 Aug 2019, Holland, Jake wrote:

| I read deprecate-interdomain-asm.  I think technically it looks
| to me to be in pretty good shape with one minor exception, but
| there are a bunch of minor language and editorial issues.
| 
| I don't object to moving the doc forward, but I think it would be
| better to tighten up the language first.  I took some quick notes
| on the issues and nits that jumped out at me as grammar errors or
| reasonably egregious problems that probably should get fixed.
| 
| Here's the notes:
| 
| Technical:
| 
| 3.2.3 Intrinsic source-control security
|    SSM is implicitly secure against unauthorized/undesired sources.
| - the only protection is against off-path attackers, not against all
|   unauthorized sources.
| 
| 
| Editorial:
| 
| Intro:
|    the recommended interdomain mode of multicast.  This recommendation
|    thus also implicitly states that all hosts and routers that are
|    expected to support interdomain multicast applications fully support
| - it's explicitly stated here, so "implicitly states" seems wrong.
|   Maybe "implies"?  Or maybe make the recommendation explicit?
| 
| 2.2.1 PIM Sparse Mode (PIM-SM)
| last paragraph:
|    To this day, there is no IETF Proposed Standard level interdomain
|    solution for IPv4 ASM multicast because MSDP was the "best" component
| - quoted '"best"' in last paragraph seems almost sarcastic--maybe
|   "most widely deployed" would be better?
| - "where" -> "were" in:
|   Other protocol options where investigated at the same time
| 
| 2.2.3 Bidir-RP
| nit: "may want to sent" -> "may want to send"
| 
| 2.3 SSM Routing Protocols
|    SSM is detailed in [RFC4607].  It mandates the use of PIM-SSM for
|    routing of SSM.  PIM-SSM as it merely a subset of PIM-SM ([RFC7761]).
| - incomplete sentence: "PIM-SSM as it merely a subset of PIM-SM ([RFC7761])."
| 
| 3.1 Observations on ASM and SSM deployments:
|    troubleshoot (complex flooding RPF rules, state attack protection,
|    filtering of undesired sources, ...).
| - should the ellipsis be filled in or exchanged for "and a number of
|   other issues"?  This whole parenthetical seems maybe better as a
|   fleshed-out explanatory sentence.
| 
| 3.2.1 Reduced network operations complexity
| last paragraph
|    PIM.  In Bidir-PIM, traffic is forwarded to an RPs instead o building
|    state as in PIM-SM.  Even in the absence of receivers.  Bidir-PIM
| 
| - "to an RP" or "to RPs", I think
| - "o" -> "of"
| - "Even in the absence of receivers." is an incomplete sentence.
| 
| 3.2.2 No network wide IP multicast group-address management
|    a source like a unicast transport protocol port number: No two
|    independent applications on the host must use same IP multicast group
| - "No" capitalized after colon is wrong I think?
| - weird phrasing in "no two applications must use the same"--something
|   maybe more like "the only coordination required is to ensure that
|   applications running on the same host don't send to the same group
|   address"
|  
| 
| 4.1 Deprecating use of ASM for interdomain multicast
|    operated by two or more separate administrative entities (domains,
|    organisations).
| - this is a weird parenthetical with unclear meaning.  I think these
|   are examples of administrative entities?  It might be best to cut
|   the parenthetical or explain with exposition here?
| 
|    are under different operator control.  A typical example of this case
|    is an SP providing IPTV (single operator domain for PIM) to
| - "SP" not defined
| 
| 4.4 Developing application guidance: SSM, ASM, service discovery
| 
| 
|    Deploying any form of IP
|    multicast solely in support of such service discovery is in general
|    not recommended (complexity, control, ...) but instead dedicated
|    service discovery via DNS [RFC6763]
| - This is not a complete sentence, and doesn't end with a period
| - "(complexity, control, ...)" is a weird list and ellipsis, probably
|   better to expand and explain.
| 
|    Best practices should be developed to explain when to use SSM in
|    applications, when ASM without (S,G) state in the network is better,
|    or when dedicated service-discovery mechanisms should be used.
| - This seems like something that would be in-scope for this document,
|   but is just left out?  (Or maybe this whole section should be cut,
|   and a note somewhere else added saying this topic is out of scope?
|   Or just the problem of ASM for service discovery should be explained
|   and advised against?)
| 
| 4.8 Not precluding Intradomain ASM
| 
| - unclosed paren at end of 2nd paragraph "(see Section 4.4."
| 
| - "does also not preclude" -> "also does not preclude"
| 
| 4.9 Evolving PIM deployments for SSM
| 
| First paragraph has several problems:
| - "with no or little changes" is weird.
| - "whener" -> whenever
| - "configuring/enabled" -> "enabled"
| - "This allows to easily migrate" - no subject in this sentence?
| - "transitioning" -> "transition"
| - "Unchanged" capitalized after colon
| 
| 5. Future interdomain ASM work
| 
| - "this document does not believe" -> something like "the mboned
|   working group does not believe"? (documents don't have beliefs)
| 
| 
| HTH.
| 
| Best,
| Jake
| 
| On 2019-07-19, 13:34, "Leonard Giuliano" <lenny=[e-mail]> wrote:
| 
|     
|     We would like to officially begin working group last call for BOTH 
|     draft-ietf-mboned-dc-deploy and 
|     draft-ietf-mboned-deprecate-interdomain-asm.  Please post whether you 
|     support/oppose the advancement of either/both of the drafts as well as any 
|     comments you may have to the list by Aug 16.  Also, please note if you are 
|     aware of any IPR involved in this drafts (we must hear from the authors 
|     about IPR).
|     
|     Most recent version of the draft can be found here:
|     https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dmboned-2Ddc-2Ddeploy_&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=iw2TU3OZ0CDpCbqeV23zdah2FoG9Do-zEmGgWTaavDg&m=iGOi3d2ESqqQiSMChau3ZzCOxK5Pm9cfhZ7bYzvjsYg&s=DQ3wIt7yMATSrjA9uFvOzDWQa47SENcnXLYb63I1mAk&e= 
|     https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dmboned-2Ddeprecate-2Dinterdomain-2Dasm_&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=iw2TU3OZ0CDpCbqeV23zdah2FoG9Do-zEmGgWTaavDg&m=iGOi3d2ESqqQiSMChau3ZzCOxK5Pm9cfhZ7bYzvjsYg&s=cZZVruG-gduaapy7KRw9QcFvVyuduuMWq9_aGu9lU6M&e= 
|     
|     _______________________________________________
|     MBONED mailing list
|     [e-mail]
|     https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_mboned&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=iw2TU3OZ0CDpCbqeV23zdah2FoG9Do-zEmGgWTaavDg&m=iGOi3d2ESqqQiSMChau3ZzCOxK5Pm9cfhZ7bYzvjsYg&s=26PkbDTiryLBxKPCWaxQKc8MQ-1bkBxn09K6BbGtJuE&e= 
|     
| 
|