Re: [dhcwg] AD review of draft-ietf-dhc-dhcpv6-failover-design

[Kim Kinnear <[e-mail]>]

Ted,

You raise the question: does the third document stand on its own, or
does it require this document.  My thinking was that the third
document absolutely requires this document.  That is part of why it
needs to be three documents.  Otherwise the final document is too complex
and cumbersome to deal with.  If we leave out the RFC 2119 language
and push all of those decisions to be made and documented in the third
document, I think we will end up with another chunk of work that
cannot be digested by the WG and IESG.

In my thinking, an actual implementation of a failover protocol will
require both this document (whatever we call it) and the third
document.  I think you could probably skip reading the first one (at
some risk), but you would absolutely require these last two.

If that approach holds up (and I've not talked to Tomek or Bernie
about it), then it sounds like we are talking significant rework of
this document.  Which isn't fun, but much of the point of *having*
this document (in my mind) is to *not* defer that work until the final
document.  The goal here is to deal with the complexity as we go, and
not have this mass of stuff that nobody can even read, let alone
review, in the final document.  So, I'd rather get this document right
and agreed to, then just say "sure, we'll deal with it later".  I
think that is one of the important reasons that this document exists,
so that we don't *have* to deal with it later.

---------------------

So, what rework are you suggesting?  Let me see if I understand.

[yes, hmmm, well, ok, but, hmmm]

Having written and deleted at least 6 different paragraphs trying to
rephrase what you are suggesting as a necessary restructuring of the
document, I'm thinking that it might be useful if you and Tomek and I
had a conference call so that we could really understand what you are
trying to convey regarding the required rework -- before we launch
into it and end up having you say "no, that wasn't what I wanted you
to do at all!".

If we all three had the document in front of us, we might be able to
at least understand what you want in much less time than it will take
us to write (and read) pages and pages of email trying to get it
nailed down.

Thoughts?

Regards -- Kim


On Feb 3, 2014, at 2:30 PM, Ted Lemon <[e-mail]> wrote:

> I've got some detailed comments, but the bottom line is that I am not ready to submit this to the IESG.   This is for two reasons.   For the first, see the last few paragraphs of this review.   The other reason is that it appears to be two documents.   One document is trying to explain the reasoning behind the choices made in developing the failover protocol.   The other is trying to specify how the protocol functions, without specifying wire format stuff.
> 
> My understanding of the plan was that there would be a requirements document, which is done.   And then there would be this document, which would be a specification of the protocol, but would not specify wire format information.   Finally, there would be a third document, which would specify the wire format.
> 
> I don't think it's a problem to do a document that describes the reasoning behind the protocol, and if the wire format document is going to specify the actual protocol, including all the MUSTs and SHOULDs and MAYs, then this document would be fine as an informational document.   However, if the third document will not stand on its own, this document has to be standards track, as it is now.   And in that case, it needs to be chopped down substantially, and the normative language needs to be thought through carefully and systematically, so that it's not scattered all over the place and so that things that ought to be validated by servers are not instead specified as requirements on administrators (e.g. the suggestions below on the CONTACT message and on 5.2 paragraph 3).
> 
> I think the right thing to do is make this document informational, get rid of the RFC2119 language and the reference to RFC2119, and do that bit in the third document.   The more I think about this, the more I think that's actually what we said we were going to do originally.   However, if you want to go forward with proposed standard, it's going to require a lot of rework.   Either way is fine with me, but the decision needs to be made.