Re: [dtn] working group last call on draft-ietf-dtn-bpbis

["Templin, Fred L" <[e-mail]>]

Hi Rick,

I agree that Ed's repository idea is a good one, and represents an organized
approach at resolving the issues. Conversely, I would be concerned that an
attempt to address all of the issues only through list posts would quickly spiral
out of control given the large and involved set of WGLC comments.

I agree that there should be some form of communication on the list that
tracks with the work that is going on in the spreadsheet, but can we have
some kind of agreement that the spreadsheet will be the place to capture
the proposed resolutions?

Thanks - Fred 

> -----Original Message-----
> From: dtn [mailto:[e-mail]] On Behalf Of Rick Taylor
> Sent: Monday, January 30, 2017 2:07 AM
> To: I-Viswanathan, Kapaleeswaran <[e-mail]>; [e-mail]; [e-mail]
> Subject: Re: [dtn] working group last call on draft-ietf-dtn-bpbis
> 
> Thank you for this Ed.
> 
> I think it is a good repository for opinions on Stephen's comments, and
> it would be nice to extend it to include other peoples comments as
> well.  But, I don't want to see the mailing list fall silent, and would
> ask that people explain their comments on the list, and then update the
> relevant row in the spreadsheet.
> 
> Can I also request some more comments and feedback on the latest TCPCL
> draft as well, please - it too is in Last Call.
> 
> Rick
> 
> On Sat, 2017-01-28 at 20:27 +0000, Birrane, Edward J. wrote:
> > I spent some time going through Stephen's comments trying to figure
> > out a good way to address them. Rather than making dozens of
> > individual posts on this mailing list, I put together a Google Doc
> > spreadsheet as a way to try and capture thoughts on the items.
> >
> > The document can be found and edited at:
> > https://docs.google.com/spreadsheets/d/1NDY3WB6JGoM0I-hNv8F03QxhNzdW8
> > aitOEOcVfoOmUM/edit?usp=sharing
> >
> > I have 3 sheets (DISCUSS, Minor, Nits) and in each sheet a column
> > where I tried to more concisely distill the comments and then provide
> > my own thoughts.  I would encourage others to make their own columns
> > in the same way. I would also encourage other rows (representing new
> > comments) to be added as we have them.
> >
> > Not trying to stop or alter discussion on the mailing list itself,
> > but I thought it might be a good idea to also have a place to capture
> > WG member opinions as we go.
> >
> > Please feel free to use if helpful.
> >
> > -Ed
> > ---
> > Edward J. Birrane, III, Ph.D.
> > Embedded Applications Group Supervisor
> > Space Exploration Sector
> > Johns Hopkins Applied Physics Laboratory
> > (W) 443-778-7423 / (F) 443-228-3839
> > From: dtn <[e-mail]> on behalf of I-Viswanathan,
> > Kapaleeswaran <[e-mail]>
> > Sent: Wednesday, January 25, 2017 9:09 AM
> > To: dtn
> > Subject: Re: [dtn] working group last call on draft-ietf-dtn-bpbis
> >
> > Hello:
> >
> > >>>>>>>>>SNIP(Fred -> Stephen -> Fred -> Stephen -> Spencer)
> > > I am still going through your comments, but one question that I
> > have
> > > on one of your points for now:
> > >
> > >     "4) it's not ok to omit
> > >      security mechanism definition, (making [BPSEC] normative and
> > >      waiting on that in the RFC editor queue would fix this, and is
> > >     IMO needed),
> > >
> > > Wouldn't that create a circular dependency?
> >
> > >That's not a problem. The RFC editor handles document clusters
> > >like that all the time.
> >
> > It is certainly the case (in my experience) that there's a history of
> > IESG Evaluations taking longer/being less enjoyable for all parties
> > when the protocol specification says "please see this other draft for
> > security" and the working group says "we owe you one draft on
> > security" ;-)
> > <<<<<<<SNIP
> >
> > I see two ways forward for Bundle Protocol specification.
> > 1.      The IPv4 way: by providing generic data structures for
> > security headers but without providing any detailed specification for
> > these headers.
> > a.      This approach will be useful to publish the transportation
> > protocol (bundle protocol) specification first and then publish the
> > security protocol (BPSec).
> > 2.      The IPv6 way: by providing clearly specified headers (data
> > structures) for interfacing transportation and security protocols.
> > a.      This approach will require a complete specification of
> > transportation and security protocols (in different documents) and
> > releasing them at the same time.
> >
> > I see this as a matter of style, because IPSec has been successfully
> > deployed on IPv4 and IPv6.
> >
> > But, purely from a documentation perspective, in its current
> > specification style, Bundle Protocol appears to be a similar to IPv6.
> > In the IPv4 document reference model, security specification (IPSec)
> > refers to transportation specification (IPv4) but not the other way
> > around. In the IPv6 document reference model, transportation (IPv6)
> > and security (IPSec) specifications cross-reference each other. The
> > document references in IP and IPSec documents are as follows.
> > 1.      IPSec –refers to--> IPv4, IPv6
> > 2.      IPv6 –refers to--> IPSec
> > 3.      IPv4 –does not refer to--> IPSec
> >
> > Bundle Protocol specifies security in extension blocks (https://tools
> > .ietf.org/html/draft-ietf-dtn-bpbis-06#section-4.3). IPv6 specifies
> > security in extension headers
> > (https://tools.ietf.org/html/rfc2460#section-4.1). In IPv6, data
> > confidentiality is specified as optional while authentication and
> > data integrity are mandatory. IPv4 specifies security as something
> > that is needed in “some simutations”
> > (https://tools.ietf.org/html/rfc791#section-1.4) and minimizes any
> > heavy-weight attention to the topic.
> >
> > The following text from IPv6 could be interesting in this regard.
> >
> > A full implementation of IPv6 includes implementation of the
> >    following extension headers:
> >
> >            Hop-by-Hop Options
> >            Routing (Type 0)
> >            Fragment
> >            Destination Options
> >            Authentication
> >            Encapsulating Security Payload
> >
> >    The first four are specified in this document; the last two are
> >    specified in [RFC-2402] and [RFC-2406], respectively.
> >
> > Best regards
> > Kapali
> >
> >
> >
> >
> > _______________________________________________
> > dtn mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/dtn
> _______________________________________________
> dtn mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dtn