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

[Hadriel Kaplan <[e-mail]>]

Hi Brett - thanks for the feedback!


On Aug 6, 2013, at 1:06 PM, Brett Tate <[e-mail]> wrote:

> 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

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 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.

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 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.

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