[Sip] RE: RAI-ART Review Comments for draft-ietf-sip-hitchhikers-guide

["Brian Stucker" <[e-mail]>]

Thanks for the updates. Replies below.

Regards,
Brian 

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[e-mail]] 
> Sent: Wednesday, November 14, 2007 12:18 AM
> To: Stucker, Brian (RICH1:AR00)
> Cc: [e-mail]; sip
> Subject: Re: RAI-ART Review Comments for 
> draft-ietf-sip-hitchhikers-guide
> 
> Thanks for the detailed review. Responses below:
> 
> Brian Stucker wrote:
> > Jonathan,
> > 
> > Thanks for putting the document together. It took quite 
> awhile to just 
> > review it!
> > 
> > Here are the comments that I have as part of the RAI-ART 
> review of the 
> > document. Apologies for the probable repeats in here from list 
> > comments, I was not able to try to correlate my comments 
> with others 
> > on the various reflectors.
> > 
> > I tried to break my comments up by section and document so 
> hopefully 
> > it's coherent in plain-text.
> > 
> > Regards,
> > Brian
> > 
> > ----
> > 
> > Section 1:
> > 
> > 
> >    This document itself is not an update to RFC 3261 
> > <http://tools.ietf.org/html/rfc3261>  or an extension to
> >    SIP.  It is an informational document, meant to guide newcomers,
> >    implementors and deployers to the SIP suite of specifications.
> > 
> > May want to change "meant to guide newcomers, implementors and 
> > deployers to the SIP suite of specifications" since many of the 
> > documents are not predicated upon SIP itself. For example, 
> RFC-4566, 
> > 3388, 3264. Also, I don't think we want to imply that this 
> document is 
> > exhaustive. Perhaps "It is an information document, meant 
> to introduce 
> > newcomers, implementors and deployers to many of the important IETF 
> > specifications associated with SIP. Specifications 
> referenced by this 
> > document were chosen based on working group consensus and the list 
> > presented here is not intended to be exhaustive or confer 
> any special 
> > status over documents not included."
> 
> Actually this is not true. The next section provides a 
> concrete criteria for inclusion. This is a criteria that was 
> discussed on the mailer and in meetings. The idea is NOT to 
> have, on a doc by doc basis, discussion and consensus on 
> whether to include it.
> 
> I changed the wording in the last sentence to "It is an 
> informational document, meant to guide newcomers, 
> implementors and deployers to the many of the specifications 
> associated with SIP."

Fair enough.

> 
> > 
> > Might also want to include some pointers to the relevant WG 
> webpages 
> > to give newcomers a place to go for further information. As well as 
> > include some boilerplate about the dangers of implementing I-D's 
> > before they become RFCs (I think this was already discussed 
> somewhat 
> > on the RAI mailing list).
> 
> I'll add the warning per Keiths comment. I'm not sure that 
> the web links bring any value in an era of Google.

Fair enough.

> 
> 
> > 
> > 
> > 
> > Section 2:
> > 
> > 	Although I agree that documents defining relevant registries
> > should be excluded, what about pointers to the registries 
> themselves?
> > Seems like some of the interop problems we wind up with are due to
> > disregard or lack of visibility of the IANA registration process to
> > implementors.
> 
> This document isn't meant to be the cure for the interop problems of 
> SIP. Its scope is to help people understand what specs form "SIP" and 
> what they are for. Thats it. That includes registry references. I am 
> going to stick hard to the original scope of this document.

Not the cure, certainly, but if the IANA registration process for SIP
extensions is considered out of scope, then perhaps a pointer to 4485
somewhere instead? Seems mostly harmless. :)

> 
> > 
> > 
> > Section 3:
> > 
> > RFC3261: 
> > 
> > 	I think it would be useful to provide a reverse-lookup list of
> > RFCs that formally update 3261 under the 3261 entry: 
> RFC-3583, RFC-4320
> > and RFC-4916. There is a statement under 4320 that it 
> formally updates
> > 3261, but there is no mention under 4916 that it formally 
> updates 3261,
> > it just looks like any other extension. Putting a pointer 
> to the SIPS
> > work as a TBD formal update to 3261 would also be good as well as
> > collapsing the "essential corrections to SIP" under the 
> 3261 entry so
> > that people don't skip over that material would be good as well.
> 
> I disagree with this. I think the IETF's view of what is an 
> 'update' vs. 
> an 'extension' is academic for implementors. I think its 
> worth noting so 
> there is no surprise, but I don't want this long list of things which 
> "are" 3261 when they each have their own RFC number.
> 
> Essential corrections is already listed in the core 
> specifications list 
> so I am not worried about it being missed.
> 
> I will mention in the sections on 3853, 4320, 4916 that they formally 
> update 3261.

Thanks.

> 
> > 
> > RFC3264:
> > 
> > 	Should we perhaps put a pointer here to the offer/answer draft
> > for further clarification of 3264 since it seems pretty 
> clear that the
> > baseline specification did not entirely capture all of the 
> interactions
> > that arise in implementations?
> 
> That document is informational. It is meant as a clarification to 
> rfc3264. The scope of the hitchhikers document doesn't include such 
> documents. If you want to further expand the scope to include 
> documents 
> that are informational clarifications, please post a note to sip and 
> raise this as proposed scope change for hitchhikers. As I said above 
> though, I disagree with any proposed increases in scope beyond our 
> original agreed set.

So you'd rather have a document that formally lists which other unclear
documents comprise the SIP specification as an aid to the implementor
for a core function of the protocol? 

Informational or not, we have real debates at the meetings around what
is correct and what is not correct in terms of how offer/answer is used
and that is captured in the offer/answer draft. 

I would agree that informational documents that do not clarify other
normative statements are out of scope, but that does not seem to be the
case here. The offer/answer draft isn't trying to make changes to
mechanism but to clarify unclear points of the existing normative
language so that people can implement the existing mechanisms properly.
It's informational only in that it does not need to be normative to do
the job. It is clearly not the same type of informative documents as
some others, or even, arguably, some of the BCP documents.

I'd argue that including a normative document that nobody uses is of
equal or lesser utility in this case.

Is this really then out of scope? Since this post is cross-posted to the
SIP list, please consider the note posted.

One thing I noticed while going back through the document during this
reply is that you include a reference to RFC-4091 which is obsoleted by
ICE. Don't know how you want to handle that one.

> 
> > 
> > RFC3325:
> > 
> > 	May want to remove the word "secure" from the description of the
> > P-Asserted-ID header description. P-Asserted-ID does not confer any
> > security of the caller ID information. It's the trust domain that
> > provides the security in contrast to a mechanism like RFC-4474. 
> 
> Changed to "network asserted".

Thanks.

> 
> 
> > 
> > RFC3581:
> > 
> > 	Rport is necessary to routing a response through a NAT, but does
> > not solve NAT traversal for SIP signaling. Perhaps a 
> pointer to outbound
> > under this RFC would be useful to highlight what you don't get with
> > rport that you need to fully address NAT traversal issues, or simply
> > remove it entirely and rely on folks to go to the NAT 
> traversal section
> > to discover it there as it's not necessary at all if you 
> have no NATs to
> > traverse (ALGs and SBCs aside).
> 
> I removed and added a pointer to the section.

Thanks.

> 
> > 
> > RFC4474:
> > 
> > 	I don't think it's necessary that we should highlight the
> > deployment size of the various RFCs in this way, especially 
> given that
> > the RFC is much newer (and has more complicated requirements) than
> > RFC3325.
> 
> Well, we'll be revising the hitchhikers guide every year or 
> so. Should 
> this statement no longer be true we can adjust it.

Fair enough.

> 
> > 
> > SIPS:
> > 
> > 	Should note that this will formally update RFC3261 when approved
> > to highlight that newcomers should ignore what's in RFC3261.
> 
> OK.

Thanks.

> 
> 
> > 
> > 
> > 
> > Section 4:
> > 
> > RFC2848/3910:
> > 
> > 	If this has seen little deployment and is very narrowly scoped,
> > then why are we including it in the guide? 
> 
> Because they are extensions and that is the scope of hitchhikers.
> 
> > 
> > RFC3372:
> > 
> > 	Widespread implementation in a limited deployment model. It
> > should be noted that it's usage is intended to be temporary as ISUP
> > endpoints are obviated from the network.
> 
> OK.

Thanks.

> 
> > 
> > RFC3960:
> > 
> > 	Early media is not just generated by the PSTN. We should be fair
> > here and acknowledge that 3960 does not solve all of the 
> various issues
> > associated with early media (without enumerating them). We 
> all know this
> > to be the case, so just a sentence or two should suffice to warn the
> > reader.
> 
> Added:
> 
> Early media
>    is a complex topic, and this specification does not fully address
>    the problems associated with it.

Perfect.

> 
> 
> > 
> > RFC3959:
> > 
> > 	We should highlight that this specification has not seen
> > widespread deployment. As of a few IETFs ago nobody 
> indicated that they
> > had developed anything with regards to this specification 
> when asked at
> > a working group meeting. This is only important in that 
> 3960 does not
> > solve all of the early media issues.
> 
> Mentioned.

Thanks.

> 
> > 
> > 
> > Shouldn't we have an entry in this section for RFC3966 to cover tel
> > URIs?
> > 
> 
> No. It does not meet the defined scope:
> 
> * SIP extensions
> * MIME objects just for SIP
> * SDP stuff just for SIP

But TEL URIs are mentioned in RFC-3261, section 19.1.6. It's not
explicitly an extension to SIP but it's used an awful lot with SIP.
Still out of scope?

> 
> > 
> > 
> > Section 5:
> > 
> > RFC3262:
> > 
> > 	PRACK is complicated, for sure, but it's used for more than just
> > PSTN interworking and is more than mildly deployed 
> depending upon the
> > environment.
> 
> Agree its not just there; the draft says that was the origin 
> of it, and 
> that it is 'most common' in PSTN interworking devices. I 
> believe this to 
> be true. I'll change "mild" to "moderate".

Fine. No need to split hairs on this one, just highlighting the point.
Thanks.

> 
> > 
> > RFC3311:
> > 
> > 	..but can be used to initiate a reliable request during session
> > establishment when a re-INVITE is not possible. This is key for
> > conveying information to an originator that cannot be conveyed in a
> > response either due to offer/answer complications or 
> because a header is
> > not allowed in a response message type. We should also 
> point out here
> > that when UPDATE is used to convey SDP, support for RFC3262 
> is required
> > in some scenarios. I don't think this is widely recognized. 
> Should also
> > call out that it can be used to convey mid-call information as well.
> 
> changed to:
> 
> <t hangText="RFC 3311, The SIP UPDATE Method (S):">RFC 3311 <xref
> target="RFC3311"/> defines the UPDATE method for SIP. This method is
> meant as a means for updating session information prior to the
> completion of the initial INVITE transaction. It can also be used to
>    update other information, such as the identity of the participant
>    <xref target="RFC4916"/>,
>    without involving an updated offer/answer exchange. It was 
> developed
> initially to support RFC 3312 <xref target="RFC3312"/> but has found
>    other uses.
> </t>

Excellent, thanks.

> 
> 
> > 
> > RFC3608:
> > 
> > 	You've captured the client perspective of the usage of
> > service-route, but from a server perspective, it's used by 
> proxies to
> > capture the route set of a registration to know how to route future
> > requests on behalf of the client. In this role it has seen greater
> > deployment and applicability.
> 
> I assume you mean the 3gpp route set validation based on 
> service route? 
> Not sure what else you might mean by "capture route set of a 
> registration to know how to route future requests". The route header 
> field in client requests is used to route future requests.
> 
> In terms of DEPLOYMENT of this, if you mean the 3gpp stuff there is 
> little deployment so far so I think my statement remains accurate.

Yes. Upon further reflection, I'll withdraw the comment.

> 
> > 
> > RFC 3841:
> > 
> > 	Should probably call out the relationship between this RFC and
> > 3840.
> 
> ok
> 
> > 
> > Need to remove duplicate entry for SDP negotiation under PSTN
> > interworking.
> 
> which duplicate entry?

Sorry, you are correct. I misread reference to [105] to be duplicate to
later reference to [106]. Nevermind.

> 
> > 
> > RFC4244:
> > 
> > 	Should remove reference to voicemail here. It has broader scope.
> > RFC4758 is intended for this purpose now (later comment).
> 
> Hmm, well I didn't think there had been WG consensus to use 4458 for 
> voicemail over 4424 - thats why it got published as 
> informational (and 
> indeed it was an individual submission IIRC).
> 
> I agree it is more broad but its original target and most 
> common usage 
> AFAIK remains voicemail. Suggest:
> 
> came to be routed to a particular destination. Its primary application
> was in support of voicemail services though it has more broad
>    applicability. </t>

Sounds fine.

> 
> 
> > 
> > 
> > Shouldn't we have an entry in this section for RFC3880, CPL?
> 
> No, it doesn't meet the scope of this document:
> 
> * SIP extensions
> * MIME objects just for SIP
> * SDP stuff just for SIP

Ok. Fair enough. I'm sure it'll come up in a BLISS document anyhow.

> 
> > 
> > 
> > 
> > Section 6:
> > 
> > RFC3605:
> > 
> > 	Should this be here and under the core specifications section? I
> > don't see this attribute show up in SDP very often 
> (pre-ICE), but it is
> > necessary for some NAT traversal solutions. Perhaps only have a
> > reference to it here? Outside of NAT traversal, is there a primary
> > reason to have this RFC or ICE in the core specifications section?
> 
> The spec says that certain docs get listed in multiple areas for 
> convenience.
> 
> It appears in the core specs because of the formal definition 
> of core specs:
> 
> <t>
> The core SIP specifications represent the set of specifications whose
> functionality is broadly applicable. An extension is broadly
> applicable if it fits into one of the following categories:
> </t>
> 
> <list style="symbols">
> 
> <t>For specifications that impact SIP session management, the
> extension would be used for almost every session initiated by a user
> agent
> </t>
> 
> <t>For specifications that impact SIP registrations, the extension
> would be used for almost every registration initiated by a user agent
> </t>
> 
> <t>For specifications that impact SIP subscriptions, the extension
> would be used for almost every subscription initiated by a user agent
> </t>
> 
> </list>
> 
> Our intention with ICE is that a client should always be 
> using it; the 
> majority of deployments involve at least one endpoint that 
> MIGHT have a 
> NAT issue, and thus ICE gets used. WHen ICE is used 3605 
> comes along for 
> the ride.

Fair enough.

> 
> > 
> > OUTBOUND:
> > 
> > 	Doesn't outbound satisfy the requirements of a broadly
> > applicable extension to SIP? Seems like if ICE is a core 
> specification,
> > that OUTBOUND should be considered one as well?
> 
> Yes, and it is listed there.
> 
> > 
> > RFC3890:
> > 
> > 	It's used extensively in other SDOs, paricularly wireless.
> 
> 
> Well, defined by an SDO is not the same as deployed. But anyway I'll 
> remove the statement in this case since its a minor spec in any case.

The text used the term 'usage' so I didn't know precisely what you meant
(usage by other specifications vs. deployment). Just trying to capture
as much as we can, I agree it's a minor spec.

> 
> > 
> > RFC4730:
> > 
> > 	Should probably explain here briefly, that 2833/4733 is most
> > commonly used to convey DTMF for SIP deployments, but the 
> difference is
> > that KPML does it on the signaling path as opposed to the 
> media path.
> > This is somewhat important given the low current deployment of KPML.
> 
> OK.
> 
> > 
> > 
> > 
> > Section 13:
> > 
> > 	Perhaps we should add an entry here for RFC4896 or make a note
> > under the entry for RFC3486 that RFC4896 updates both RFC3486 and
> > RFC3485 which is the static dictionary for SIP (which provides the
> > explicit coupling between SIGCOMP and SIP eluded to in the 
> draft text).
> > The important bit for an entry to RFC3485 is that there are 
> a few bugs
> > in the dictionary such that you'd need to refer to section 
> 12 of RFC4896
> > to come up with a BCP implementation.
> 
> I added 4896.
> 3486 doesn't meet the scope of hitchhikers:
> 
> * SIP extensions
> * MIME objects just for SIP
> * SDP stuff just for SIP

Huh? How is 3486 not an extension to SIP? It defines a URI parameter for
the SIP/SIPS URI scheme along with other normative behavior specifically
for SIP (it's even in the title).

> 
> > 
> > 
> > 
> > Section 14:
> > 
> > I think we should add an entry for RFC4758 to capture the voicemail
> > service URI as another important service URI RFC.
> 
> added.
> 
> > 
> > 
> > Section 15:
> > 
> > RFC3853:
> > 
> > 	May want to state that RFC3853 'formally' updates RFC3261, and
> > put a pointer to this from the core specifications section 
> as a result
> > since it's a correction to 3261.
> 
> Update noted.
> However its not core since SMIME is not used in every call. See above 
> for the definition of a core spec. Just because a document 
> updates SIP 
> does not make it a core spec.

Fair enough.

> 
> > 
> > RFC3893:
> > 
> > 	Should RFC3893 entry simply say something to the effect of 'use
> > RFC4474', or be dropped altogether?
> 
> It basically does say that.

Ok. Agree.

> 
> > 
> > RFC3329:
> > 
> > 	There are now three possible security models now in 3GPP: HTTP
> > DIGEST, AKA, and early-IMS. As early-IMS doesn't really 
> involve much in
> > the way of security mechanisms within the SIP protocol, the 
> coexistance
> > of it with digest or AKA seems to be very probable. Perhaps 
> we should
> > just remove the last sentence and leave it up to the reader 
> to decide if
> > it's needed for their purpose.
> 
> I think this is a useful piece of guidance. I know I have 
> answered this 
> question many times about whether this feature is needed.

Ok. I hadn't even heard that question, but if it's being asked, then I'm
ok with the reader figuring it out for themselves either way.

> 
> > 
> > 
> > 
> > Section 16:
> > 
> > Shouldn't we perhaps move RFC4796 from section 7 to this section?
> 
> Why?

Section 16: 

16.  Instant Messaging, Presence and Multimedia

   SIP provides extensions for instant messaging, presence, and
   multimedia.

Entry for RFC4796:

  RFC 4796, The SDP (Session Description Protocol) Content Attribute
   (S):  RFC 4796 [94] defines an SDP attribute for describing the
      purpose of a media stream.  


Seems more related to multimedia than that it's a minor extension
although I don't feel strongly either way. If you want to leave it
alone, I'm ok with that. Was only a suggestion.

> 
> > 
> > 
> > Section 17:
> > 
> > Providing a pointer off to ECRIT seems useful here.
> 
> That scope comment again.

Ok.

> 
> Thanks,
> Jonathan R.
> 
> -- 
> Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
> Cisco Fellow                                   Parsippany, NJ 
> 07054-2711
> Cisco Systems
> [e-mail]                              FAX:   [phone]
> http://www.jdrosen.net                         PHONE: [phone]
> http://www.cisco.com
> 


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [e-mail] for questions on current sip
Use [e-mail] for new developments on the application of sip