Subject: Re: [dispatch] Chair question around draft-klatsky-dispatch-ipv6-impact-ipv4

From: "Hutton, Andrew" <[email-masked]>
Date: Mon, 1 Jul 2013 09:48:24 +0000

See below.

> -----Original Message-----
> From: Olle E. Johansson [mailto:[email-masked]]
> Sent: 29 June 2013 08:07
> To: Cullen Jennings (fluffy)
> Cc: Olle E. Johansson; Rifaat Shekh-Yusef; Gonzalo Salgueiro
> (gsalguei); [email-masked]; Hutton, Andrew;
> [email-masked] list
> Subject: Re: Chair question around draft-klatsky-dispatch-ipv6-impact-
> ipv4
> 
> 
> 29 jun 2013 kl. 00:28 skrev "Cullen Jennings (fluffy)"
> <[email-masked]>:
> 
> >
> > The chairs are trying to figure out how to frame the purpose of this
> draft as that helps us figure out what to do with it. Three questions
> to the authors (but happy to hear from anyone):
> >
> > 1) Guidance or Standard ?
> >
> > My current understanding of the draft is that it does not require any
> updates or changes to any existing RFC. It does not specify new
> normative behavior. (and I see it is informational) It seems to be more
> a collection of scenarios that a implementer might want to consider but
> does not change any normative behavior.
> >
> > Is my understanding roughly correct?
> Yes.

Also agree.

> >
> >
> > 2) Operators or Implementers ?
> >
> > Another ways of looking at this draft, seem to be advice to operators
> to use DNS names instead of IP addresses that might not be supported.
> That will allow v4/v6 interop mechanism at layer 3 to come into play.
> >
> > Does the draft want to be advice to operators about how to use IP
> addresses and DNS names in SIP to avoid the problems raised in the
> draft?
> Good question. I think that is the general religion of SIP - and we've
> been working with it at SIPit - "test using DNS, not IP addresses".
> I personally don't think we should add it to this specific document at
> this point as it may generate a lot of discussions and lead to happy-
> eyeballs whcih is in scope for the other documents.
> 
> I need guidance from those of you that are more experienced in the IETF
> process here. WHile I would love to add another argument for not using
> numeric IP addresses.
> 

I had thought of the draft as being for implementers rather than operators and that is probably where the focus should stay. 

> >
> >
> > 3) Scope
> >
> > Nearly every section of the draft raises as many questions in my mind
> as it answers. Is the intend that this draft is "close to done" with
> some review or is it more that this draft is just the starting point of
> a much larger effort? ( I can give examples but I want to focus on the
> big picture not the questions raised in my mind )
> 
> I think this draft should stay "problem statement" more than solution.
> At this point we just want to alert and wake up everyone saying "oh, I
> only do IPv4 so I don't have to bother". And that fact needs to be out
> there soon.
> 
> If there are issues in this draft that lacks a solution in the current
> set of RFCs we need to handle that, but in my head that would be a
> separate document.
> 
> We might make it a bit more clear that this is a problem statement.
> Again, I'm the newbie in this process so this is just my 5 öre
> contribution :-)
> 

Agree with Olle this is intended to be a problem statement and to promote awareness and discussion so personally I would like to be open to additional issues being raised and documented so would not say it is close to done at this stage.

> >
> >
> > Cullen
> >
> > PS - As a chair - this type of draft is the hardest. It's hard to
> know what is the best thing to do with this draft until I get a clear
> picture of what work this is proposing for IETF.
> 
> 
> /O

---

From: "Olle E. Johansson" <[email-masked]>
Date: Tue, 2 Jul 2013 17:04:36 +0200

>>> 1) Guidance or Standard ?
Just found this statement in the introduction (section 1)

"The scenarios outlined in this document are intended as guidance for
   application developers to help identify solutions to resolve the
   identified interoperability challenges. "

Maybe we should add them more clearly in the abstract.
/O