3GPP SIP URI Inter-Operator Traffic Leg Parameter
RFC 7549

Note: This ballot was opened for revision 04 and is now closed.

(Richard Barnes) Yes

(Spencer Dawkins) Yes

Comment (2015-02-04 for -04)
No email
send info
I didn't figure out that the values were an enumerated set until Section 5/page 7. That's not horrible, but I'd think it would be easier for first-time readers if you said something like 
    
    This draft defines the following iotl values: 

    o "homeA-homeB" 
    o "homeB-visitedB" 
    o "visitedA-homeA"
    o "homeA-visitedA" 
    o "visitedA-homeB" 

early in the document. Not a big deal, just a suggestion. Note that I'm a Yes.

(While typing this, I noticed that " visitedA-homeB" had a leading space in the ABNF. I'm not wizard enough to know whether that matters, so I thought I'd ask before AUTH48 ...)

(Jari Arkko) No Objection

Comment (2015-02-05 for -04)
No email
send info
There has been a discussion of changes with respect to a Gen-ART review by Robert Sparks. It would be good to ensure that this discussion is finished and the necessary changes are folded in, before the draft is approved.

(Alia Atlas) No Objection

(Benoît Claise) No Objection

Comment (2015-02-04 for -04)
No email
send info
While reading through the draft I wondered a few times: "but what does iotl stand for?"
Maybe I'm stupid, maybe I simply didn't pay enough attention to the document title, or maybe I should stop reading drafts late at night, but a simple reference to "Inter Operator Traffic Leg", next to iotl, somewhere in the intro would have helped me. Thanks Richard for showing me the light :-)

Alissa Cooper No Objection

Comment (2015-02-04 for -04)
No email
send info
This text appears in both Sections 1 and 2, but only needs to be stated once:
"The SIP URI 'iotl' parameter defined in this document has known uses
   in 3GPP networks.  Usage in other networks is also possible."
   
In Section 7:
s/The information/The information in the iotl parameter/

(Adrian Farrel) No Objection

(Stephen Farrell) (was Discuss) No Objection

Comment (2015-02-12 for -05)
No email
send info
Thanks for handling my (pretty vague:-) discuss


--- OLD Comments below, I didn't check if changes resulted
or not, happy to chat about it if you want.

- As usual, I dislike that we're making special assumptions
about 3gpp networks. I think any stuff like this is liable to
leak over so saying "just 3gpp" should not be a get out of
jail card.

- section 3 does not actually define any uses for the iotl
parameter but simply repeats page 4 as far as I can see.

- 5.1, last para: I don't get how the "must not" there doesn't
apply here and say that this entire idea is busted - can you
explain?

- section 7: the 2119 terms here are bogus.

(Joel Jaeggli) No Objection

Barry Leiba No Objection

Comment (2015-02-04 for -04)
No email
send info
In Sections 5.2 and 6.2, you always show the parameter values in specific case, such as "homeA-homeB", though they're case-insensitive, and could just as well be presented as "homea-homeb" or "HOMEA-HOMEB".  I wonder whether it's worth reminding readers of that with a sentence in Section 6.2, just to avoid bad implementations.  Or is that simply a well-enough-known thing in SIP that it's not worth bothering?

And the error in the ABNF that Spencer points out does matter, and needs to be fixed.  I have every confidence that it will be.

(Ted Lemon) No Objection

(Kathleen Moriarty) No Objection

Comment (2015-02-04 for -04)
No email
send info
Thanks for your work on this draft, I just have one question:

Should this draft have a reference to either the framework or a base SIP RFC that describes security and privacy considerations?

(Pete Resnick) No Objection

(Martin Stiemerling) No Objection