Subject: Re: [pim] WGLC on draft-ietf-pim-explicit-rpf-vector-00

From: IJsbrand Wijnands <[email-masked]>
Date: Mon, 1 Jul 2013 09:16:47 +0200

Bharat,

> Ice: We can change 'will' into 'may likely'.
> 
> <Bharat>: That may not solve the problem. My thinking is that we should allow it to compare metrics as it is. If they are same, they will anyway fallback on the other parameters like IP address. So why to add a special case here?

I'm calling this out because in 99% of the cases the Metric will be zero. The draft does not say that Metric MUST not be used. If I change to 'may likely', I think it solves the problem.

> 
>> • In section 9, "support the Explicit Vector MUST never" -> "support the Explicit Vector attribute MUST never"
> 
> Ice: The draft is about documenting 'Explicit Vector' as a new PIM attribute. Is it not obvious that if we talk about 'Explicit Vector', this is an attribute?
> 
> <Bharat>: While I agree that it is obvious but my thinking is that it is better to be consistent across. I suggested this because most of the places this draft uses 'Attribute' as well.

Ok.

>> • Will things work if both Explicit RPF vector and normal RPF vector attributes are available in a PIM join? Or should we say that they cannot be used together?
> 
> Ice: Nothing prevents that.
> 
> <Bharat>: I think it is better to clarify this in the document. This will help an implementor as well as a reader.

Do you see an issue that needs to be clarified specific to this?

>> • In security consideration, should not we also mention that Explicit RPF Vector Attribute itself does not add any security implications on PIM-SM functioning.
> 
> Ice: Does -01 not already address this?
> 
> <Bharat>: It is mentioned but not from this new attribute perspective, please relook at that text.

"RPF Vector" needs to be changed to "Explicit RPF Vector", is that what you mean?

Thx,

Ice.

> 
> 
> 
> 
> **************** CAUTION - Disclaimer *****************
> This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely 
> for the use of the addressee(s). If you are not the intended recipient, please 
> notify the sender by e-mail and delete the original message. Further, you are not 
> to copy, disclose, or distribute this e-mail or its contents to any other person and 
> any such actions are unlawful. This e-mail may contain viruses. Infosys has taken 
> every reasonable precaution to minimize this risk, but is not liable for any damage 
> you may sustain as a result of any virus in this e-mail. You should carry out your 
> own virus checks before opening the e-mail or attachment. Infosys reserves the 
> right to monitor and review the content of all messages sent to or from this e-mail 
> address. Messages sent to or from this e-mail address may be stored on the 
> Infosys e-mail system.
> ***INFOSYS******** End of Disclaimer ********INFOSYS***
>

---

From: Bharat Joshi <[email-masked]>
Date: Mon, 1 Jul 2013 07:42:51 +0000

Hi,

         Few replies in line with <Bharat>.

Regards,
Bharat

<Bharat>: Ok.

<Bharat>: I think there is a need simply because there are multiple join attributes. As this new join attribute does not put any restriction on how the multiple join attributes are used, I think it will be good to add some text on this.

<Bharat>: What I was trying to say is that we should add some text which reflects that adding a new join attribute does not add any new security issues for PIM. But if you think that current one is sufficient so let us stick to that till the IESG suggest something.

---

From: IJsbrand Wijnands <[email-masked]>
Date: Mon, 1 Jul 2013 09:53:55 +0200

Bharat,

> <Bharat>: I think there is a need simply because there are multiple join attributes. As this new join attribute does not put any restriction on how the multiple join attributes are used, I think it…

Ok, we can do that.

> <Bharat>: What I was trying to say is that we should add some text which reflects that adding a new join attribute does not add any new security issues for PIM. But if you think that current one is…

I don't think it needs to say more then RFC 5496 already does.

Thx,

Ice.

---

From: Stig Venaas <[email-masked]>
Date: Mon, 15 Jul 2013 10:22:02 -0700

Hi

Bharat, you suggested several changes during WGLC, can you check if the
latest revision addresses your comments?

See
http://tools.ietf.org/html/draft-ietf-pim-explicit-rpf-vector-02

Stig

---

From: Bharat Joshi <[email-masked]>
Date: Wed, 17 Jul 2013 06:28:14 +0000

Stig,

     I am running a little low on time but I will do this review by next week for sure.

Regards,
Bharat
________________________________________
From: [email-masked] [[email-masked]] on behalf of Stig Venaas [[email-masked]]
Sent: Monday, July 15, 2013 10:52 PM
To: Bharat Joshi
Cc: Mike McBride; [email-masked]
Subject: Re: [pim] WGLC on draft-ietf-pim-explicit-rpf-vector-00

Hi

See

Stig

_______________________________________________
pim mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pim