Subject: [straw] draft-ietf-straw-b2bua-loop-detection-01: comments

From: Brett Tate <[email-masked]>
Date: Tue, 6 Aug 2013 17:06:36 +0000

Hi,

The following are few comments concerning draft-ietf-straw-b2bua-loop-detection-01.

Additionally, the following link truncates the draft within section 11 [RFC5393] reference:

http://tools.ietf.org/html/draft-ietf-straw-b2bua-loop-detection-01

Thanks,
Brett

--------

Section 3 paragraph 2: "Media- plane" should likely be "Media-plane".

Section 5 paragraph 2: If "as defined in [RFC3261]" is part of the normative statement, draft-ietf-straw-sip-traceroute indicates alternative behavior.

Section 5 paragraph 3: "any requests" should potentially be "all requests" or "any request".

Section 5 paragraph 4: The paragraph should likely be reworded.  The normative statement appears to only apply to B2BUAs that remove Record-Route.  Similarly, I think that the normative statement should be loosed to allow a B2BUA to behave the same way for mid-dialog requests.  For instance, the paragraph can mention that section 5 applies requests outside of dialog; B2BUAs MAY act the same way for mid-dialog requests although it will not be interoperable with devices that set Max-Forwards based upon the number Route entries.

Section 7 paragraph 1: I'm not sure if completely accurate since the draft prevents (excluding the draft's next paragraph) the use of smaller Max-Forwards while within deployments bordered by B2BUAs (i.e. reduced Max-Forwards upon entry and allowed to expand Max-Forwards as needed on exit).  More specifically excluding the configurable overrides, the draft prevents a subnet temporarily putting a smaller cap on Max-Forwards per RFC 5393 section 7.1 until the request leaves the subnet.

Section 11 final reference: The draft's date and author list do not reflect version 2.  If it matters, it is also a normative reference to an informational draft.

This email is intended solely for the person or entity to which it is addressed and may contain confidential and/or privileged information. If you are not the intended recipient and have received this email in error, please notify BroadSoft, Inc. immediately by replying to this message, and destroy all copies of this message, along with any attachment, prior to reading, distributing or copying it.

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 19 Aug 2013 09:20:26 -0400

Hi Brett - thanks for the feedback!

> http://tools.ietf.org/html/draft-ietf-straw-b2bua-loop-detection-01

Yes it does... weird. 

> Section 3 paragraph 2: "Media- plane" should likely be "Media-plane".

Yup.

> Section 5 paragraph 2: If "as defined in [RFC3261]" is part of the normative statement, draft-ietf-straw-sip-traceroute indicates alternative behavior.

I think the current text is ok - we just need to update the traceroute one to update this draft, right?
Otherwise it creates a circular dependency, and really this loopback-detect draft doesn't depend on the traceroute one at all.
(i.e., one needn't read the traceroute draft to implement this loop-detect one)

> Section 5 paragraph 3: "any requests" should potentially be "all requests" or "any request".

Yup.

> Section 5 paragraph 4: The paragraph should likely be reworded.  The normative statement appears to only apply to B2BUAs that remove Record-Route.  Similarly, I think that the normative statement s…

Agreed.

> Section 7 paragraph 1: I'm not sure if completely accurate since the draft prevents (excluding the draft's next paragraph) the use of smaller Max-Forwards while within deployments bordered by B2BUA…

RFC 5393 rejected that model - the entire section 7.1 in RFC 5393 are things it considered and rejected.

Ultimately if a B2BUA implementor or operator wishes to override the behavior dictated in this draft, there's nothing we can do to stop them.  They're just not complying with the draft, and loops might happen or requests might fail prematurely.

> Section 11 final reference: The draft's date and author list do not reflect version 2.  If it matters, it is also a normative reference to an informational draft.

The draft-01 online only references standards-track docs.  I'm not sure what you're referring to.

-hadriel

---

From: Brett Tate <[email-masked]>
Date: Mon, 19 Aug 2013 15:39:38 +0000

Hi Hadriel,

Thanks for the response.  Reply is inline

> > Section 5 paragraph 2: If "as defined in [RFC3261]" is part 
> > of the normative statement, draft-ietf-straw-sip-traceroute 
> > indicates alternative behavior.
> 
> I think the current text is ok - we just need to update the 
> traceroute one to update this draft, right?

The plan sounds okay to me.

> > Section 7 paragraph 1: I'm not sure if completely accurate 
> > since the draft prevents (excluding the draft's next 
> > paragraph) the use of smaller Max-Forwards while within 
> > deployments bordered by B2BUAs (i.e. reduced Max-Forwards 
> > upon entry and allowed to expand Max-Forwards as needed on 
> > exit).  More specifically excluding the configurable 
> > overrides, the draft prevents a subnet temporarily putting 
> > a smaller cap on Max-Forwards per RFC 5393 section 7.1 until 
> > the request leaves the subnet.
> 
> Ultimately if a B2BUA implementor or operator wishes to override the
> behavior dictated in this draft, there's nothing we can do to stop
> them.  They're just not complying with the draft, and loops might
> happen or requests might fail prematurely.

I agree except "loops might happen or requests might fail prematurely".  More specifically, it prevents a subnet from doing better than RFC 5393 and this draft (although I'm not sure if worth discussing within section 7).

It is easier to explain while assuming new header Max-Forwards-Subnet-Entry which contains name of the subnet and the Max-Forwards value when entered.  If the subnet's border elements support the new header (and middle boxes don't remove/replace it), there is no premature fail or loop.

For example, border entry B2BUA receives INVITE with Max-Forwards 255.  Entry B2BUA adds Max-Forwards-Subnet-Entry containing 255 and Max-Forwards 10.  INVITE bounces around within the subnet and reaches exit B2BUA with Max-Forwards 1 and Max-Forwards-Subnet-Entry 255.  The exit B2BUA strips the Max-Forwards-Subnet-Entry and sends Max-Forwards with something like 245.

Thus no loop or premature fail.  Similarly if there was a loop prior to exiting the controlled subnet environment, it would not have had to bounce around the INVITE so many times prior to fail when it knows that the smaller max is appropriate while within the subnet.

> > Section 11 final reference: The draft's date and author list 
> > do not reflect version 2.  If it matters, it is also a normative 
> > reference to an informational draft.
> 

I'm basically referring to the same nit reported by 
http://tools.ietf.org/tools/idnits/

  Checking references for intended status: Proposed Standard
  ----------------------------------------------------------------------------

     (See RFCs 3967 and 4897 for information about using normative references
     to lower-maturity documents in RFCs)

  ** Downref: Normative reference to an Informational draft:
     draft-ietf-straw-b2bua-taxonomy (ref. 'I-D.ietf-straw-b2bua-taxonomy')

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 20 Aug 2013 12:00:51 +0000

Hi,

>>> Section 11 final reference: The draft's date and author list do not 
>>> reflect version 2.  If it matters, it is also a normative reference 
>>> to an informational draft.
>> 
> I'm basically referring to the same nit reported by http://tools.ietf.org/tools/idnits/
>

As the b2bua-tax document is informational, I guess it has to be listed as an informative reference.

Regards,

Christer