Subject: [Softwires] Stephen Farrell's No Objection on draft-ietf-softwire-dslite-multicast-16: (with COMMENT)

From: "Stephen Farrell" <[email-masked]>
Date: Tue, 31 Jan 2017 05:44:46 -0800

Stephen Farrell has entered the following ballot position for
draft-ietf-softwire-dslite-multicast-16: 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-softwire-dslite-multicast/

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

- IPR: so we have a late IPR declaration that sys
RAND+royalty but yet the filing refers to the I-D
that preceded the application and there's a common
author/inventor. Sheesh. But the WG did consider it
and were ok going ahead from a look at the list.
(So there's no need to reply to my whining here:-)

- 6.3: Is RFC7739 worth a mention here?  Not sure
myself.

- section 9: I'd have thought that this solution
reduced the potential for a DoS compared to the
previous situation where multicast traffic is 
mapped to unicast? If so, worth a mention?

---

From: <[email-masked]>
Date: Tue, 31 Jan 2017 14:20:11 +0000

Re-,

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Stephen Farrell [mailto:[email-masked]]
> Envoyé : mardi 31 janvier 2017 14:45
> À : The IESG
> Cc : [email-masked]; softwire-
> [email-masked]; [email-masked]; [email-masked]
> Objet : Stephen Farrell's No Objection on draft-ietf-softwire-dslite-
> multicast-16: (with COMMENT)
> 
[Med] Given that the document does not discuss how the identification field is valued and that RFC7739 provides algo EXAMPLES, I tend to not cite it here. 

> mapped to unicast? If so, worth a mention?
[Med] What about?

"Unlike solutions that map IPv4 multicast flows to IPv6 unicast flows, this document does not exacerbate Denial-of-Service (DoS) attacks."

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 31 Jan 2017 14:56:14 +0000

Hiya,

On 31/01/17 14:20, [email-masked] wrote:
> Re-,
> 
> Please see inline.
> 
> Cheers, Med
> 
>> -----Message d'origine----- De : Stephen Farrell
>> [mailto:[email-masked]] Envoyé : mardi 31 janvier 2017
>> 14:45 À : The IESG Cc :
>> [email-masked]; softwire- 
>> [email-masked]; [email-masked]; [email-masked] Objet :
>> Stephen Farrell's No Objection on draft-ietf-softwire-dslite- 
>> 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.
>> 
>> 
>> RAND+royalty but yet the filing refers to the I-D that preceded the
>> application and there's a common author/inventor. Sheesh. But the
>> WG did consider it and were ok going ahead from a look at the
>> list. (So there's no need to reply to my whining here:-)
>> 
>> - 6.3: Is RFC7739 worth a mention here?  Not sure myself.
>> 
> [Med] Given that the document does not discuss how the identification
> field is valued and that RFC7739 provides algo EXAMPLES, I tend to
> not cite it here.
> 
>> - section 9: I'd have thought that this solution reduced the
>> potential for a DoS compared to the previous situation where
>> multicast traffic is mapped to unicast? If so, worth a mention?
>> 
> [Med] What about?
> 
> "Unlike solutions that map IPv4 multicast flows to IPv6 unicast
> flows, this document does not exacerbate Denial-of-Service (DoS)
> attacks."
> 

That seems a bit of a negative way to put it. But if
you think it's worth a mention, the it'll do:-)

S.