Re: Re: [ssm] another last call for draft-ietf-ssm-arch - ending 3/24

[Hugh Holbrook <holbrook@cisco.com>]

Hey, Pekka.  

I was just finishing up the final tweaks to the draft realize that I
never responded to your editorial comments from a few months back.  I
took pretty much all of your suggestions.  For the record, here's what
I did.

-Hugh

> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
> "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
> document are to be interpreted as described in RFC 2119 [RFC 2119].
> 
> ==> I believe this should be at the end of Introduction, but not sure..?

RFC2119 says anywhere near the beginning is ok.

> designated as source-specific multicast (SSM) destination addresses and
> are reserved for use by source-specific applications and protocols.  For
> IP version 6 (IPv6), the address prefix FF3x::/32 is reserved for
> Source-Specific Multicast use.  It defines an extension to the Internet
> 
> ==> source-specific multicast vs Source-Specific Multicast -- pick one for
> consistancy
> 
> Using the terminology of [IPv6-UBM], this means that P=1, T=1, and
> plen=0 for any SSM address.

Done

> ==> "means that x=y for any address", is ok but could be a bit better,
> maybe:
> 
> Using the terminology of [IPv6-UBM], all SSM addresses must have P=1, T=1, and
> plen=0.

Done

> within the FF3x::/96 range, but a system should treat all of FF3x::/32
> as an SSM address, to allow for compatibility with possible future uses
> 
> ==> s/an SSM address/SSM addresses/

Done.

> referred to as a "channel."  In contrast to the ASM model of RFC 1112,
> 
> ==> s/."/"./ ?

I think ." is actually the right punctuation.


>   Identifier:           G                   S,G
>   Receiver Operations:  join, leave         subscribe, unsubscribe
> 
> ==> s/subscribe/Subscribe/, s/unsubscribe/Unsubscribe/

Done.

> host IP module sends an unsubscription request for that channel out
> interface I.
> 
> ==> s/interface/the interface/, or "on interface".

I used "to interface."

> address range for IPv4).  For IPv6, the randomization should apply to
> the lower 32 bits of the address.
> 
> ==> s/lower/lowest/ ?

Done.

> subscriber would be delivered to another's IP module, which would then
> have to reject the datagram.
> 
> ==> perhaps s/reject/discard/ would be slightly better?

Done.

> specify the required  modifications to those protocols to support SSM.
> 
> ==> s/required  /required / (extra space)

Done

> 7.  Security Considerations
> 
> ==> add a 1-2 line summary of the subsections here.

How's this?

  This section outlines security issues pertaining to SSM.  The
  following topics are addressed: limitations of IPSec,
  denial of service attacks, source spoofing, and security
  issues related to administrative scoping.
  
> To reduce the damage from such an attack, a router MAY have
> configuration options to limit the following items:

> 
> ==> s/limit/limit, for example,/ ?  the list is not meant to be exclusive,
> and it's a MAY after all..
> 
> risks unduly burdening the network infrastructure by deliver (S,G)

Done.

> ==> s/deliver/delivering/

Done.

> -- 
> Pekka Savola                 "You each name yourselves king, yet the
> Netcore Oy                    kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
> 
> _______________________________________________
> ssm mailing list
> ssm@ietf.org
> https://www1.ietf.org/mailman/listinfo/ssm
_______________________________________________
ssm mailing list
ssm@ietf.org
https://www1.ietf.org/mailman/listinfo/ssm