Skip to main content

3GPP SIP URI Inter-Operator Traffic Leg Parameter
draft-holmberg-dispatch-iotl-06

Yes

(Richard Barnes)

No Objection

(Adrian Farrel)
(Alia Atlas)
(Joel Jaeggli)
(Martin Stiemerling)
(Pete Resnick)
(Ted Lemon)

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

Richard Barnes Former IESG member
Yes
Yes (for -04) Unknown

                            
Spencer Dawkins Former IESG member
Yes
Yes (2015-02-04 for -04) Unknown
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 ...)
Adrian Farrel Former IESG member
No Objection
No Objection (for -04) Unknown

                            
Alia Atlas Former IESG member
No Objection
No Objection (for -04) Unknown

                            
Alissa Cooper Former IESG member
No Objection
No Objection (2015-02-04 for -04) Unknown
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/
Barry Leiba Former IESG member
No Objection
No Objection (2015-02-04 for -04) Unknown
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.
Benoît Claise Former IESG member
No Objection
No Objection (2015-02-04 for -04) Unknown
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 :-)
Jari Arkko Former IESG member
No Objection
No Objection (2015-02-05 for -04) Unknown
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.
Joel Jaeggli Former IESG member
No Objection
No Objection (for -04) Unknown

                            
Kathleen Moriarty Former IESG member
No Objection
No Objection (2015-02-04 for -04) Unknown
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?
Martin Stiemerling Former IESG member
No Objection
No Objection (for -04) Unknown

                            
Pete Resnick Former IESG member
No Objection
No Objection (for -04) Unknown

                            
Stephen Farrell Former IESG member
(was Discuss) No Objection
No Objection (2015-02-12 for -05) Unknown
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.
Ted Lemon Former IESG member
No Objection
No Objection (for -04) Unknown