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

["Holland, Jake" <[e-mail]>]

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://datatracker.ietf.org/doc/draft-ietf-mboned-dc-deploy/
    https://datatracker.ietf.org/doc/draft-ietf-mboned-deprecate-interdomain-asm/
    
    _______________________________________________
    MBONED mailing list
    [e-mail]
    https://www.ietf.org/mailman/listinfo/mboned