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

[Brett Tate <[e-mail]>]

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

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.
> 
> The draft-01 online only references standards-track docs.  I'm not sure
> what you're referring to.

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')