Re: [Int-area] I-D Action: draft-ietf-intarea-broadcast-consider-01.txt
Hi, all, I thought I mentioned this before, but regardless: This doc should include a discussion of RFC3819, which explains where and why broadcast is important in the Internet architecture. Joe On 11/2/2016 3:34 AM, Rolf Winter wrote: > Hi Brian, > > great that you found the document useful. Since the 00 version a lot > has changed, and you might want to look at it again. We will look at > RFC 5374 and see where it should be mentioned in the document. Thanks > for the hint! > > Best, > > Rolf > > Am 10/31/16 um 8:25 PM schrieb Brian E Carpenter: >> Rolf, >> >> I read this draft (the -00 version) recently, since I'm co-author of >> draft-ietf-anima-grasp, which relies heavily on link-local multicast. >> I did >> find it useful, although I didn't in the end change anything as a >> result. >> >> Should you mention the MSEC work and RFC 5374 in particular? >> >> Regards >>Brian Carpenter >> >> On 01/11/2016 03:08, Rolf Winter wrote: >>> Hi, >>> >>> Apologies, but I screwed up the draft naming convention and just >>> uploaded the 00 and a 01 version with correct naming. The 00 version is >>> the one that was adopted by the WG, the 01 version now addresses the >>> comments made by Eliot and Stephane. >>> >>> Sorry for the confusion. >>> >>> Best, >>> >>> Rolf >>> >>> Am 10/31/16 um 3:05 PM schrieb internet-dra...@ietf.org: A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Area Working Group of the IETF. Title : Privacy considerations for IP broadcast and multicast protocol designers Authors : Rolf Winter Michael Faath Fabian Weisshaar Filename: draft-ietf-intarea-broadcast-consider-01.txt Pages : 10 Date: 2016-10-31 Abstract: A number of application-layer protocols make use of IP broadcasts or multicast messages for functions like local service discovery or name resolution. Some of these functions can only be implemented efficiently using such mechanisms. When using broadcasts or multicast messages, a passive observer in the same broadcast/ multicast domain can trivially record these messages and analyze their content. Therefore, broadcast/multicast protocol designers need to take special care when designing their protocols. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-intarea-broadcast-consider/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-intarea-broadcast-consider-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-intarea-broadcast-consider-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area >>> >>> ___ >>> Int-area mailing list >>> Int-area@ietf.org >>> https://www.ietf.org/mailman/listinfo/int-area >>> > > ___ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] I-D Action: draft-ietf-intarea-broadcast-consider-01.txt
Hi Rolf, I apologize. I had entirely forgotten about this draft. I've put out very much a -00 of my own draft-lear-network-helps-01.txt. The key point of my draft, to expropriate from Ecclesiastes, is simply this: there is a time for sharing. But when doing so, (a) do so by design, (b) use encryption where practicable, and (c) consider the tradeoffs (we must acknowledge that there are tradeoffs, as engineers). It is ABSOLUTELY drafty, but I would like the idea of combining some concepts. What do people think? I know mine stretches a bit beyond the intarea... Eliot On 10/31/16 3:08 PM, Rolf Winter wrote: > Hi, > > Apologies, but I screwed up the draft naming convention and just > uploaded the 00 and a 01 version with correct naming. The 00 version > is the one that was adopted by the WG, the 01 version now addresses > the comments made by Eliot and Stephane. > > Sorry for the confusion. > > Best, > > Rolf > > Am 10/31/16 um 3:05 PM schrieb internet-dra...@ietf.org: >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Internet Area Working Group of the >> IETF. >> >> Title : Privacy considerations for IP broadcast and >> multicast protocol designers >> Authors : Rolf Winter >> Michael Faath >> Fabian Weisshaar >> Filename: draft-ietf-intarea-broadcast-consider-01.txt >> Pages : 10 >> Date: 2016-10-31 >> >> Abstract: >>A number of application-layer protocols make use of IP broadcasts or >>multicast messages for functions like local service discovery or name >>resolution. Some of these functions can only be implemented >>efficiently using such mechanisms. When using broadcasts or >>multicast messages, a passive observer in the same broadcast/ >>multicast domain can trivially record these messages and analyze >>their content. Therefore, broadcast/multicast protocol designers >>need to take special care when designing their protocols. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-intarea-broadcast-consider/ >> >> There's also a htmlized version available at: >> https://tools.ietf.org/html/draft-ietf-intarea-broadcast-consider-01 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-intarea-broadcast-consider-01 >> >> >> >> Please note that it may take a couple of minutes from the time of >> submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> ___ >> Int-area mailing list >> Int-area@ietf.org >> https://www.ietf.org/mailman/listinfo/int-area >> > > ___ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area > signature.asc Description: OpenPGP digital signature ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] I-D Action: draft-ietf-intarea-broadcast-consider-01.txt
Hi Brian, great that you found the document useful. Since the 00 version a lot has changed, and you might want to look at it again. We will look at RFC 5374 and see where it should be mentioned in the document. Thanks for the hint! Best, Rolf Am 10/31/16 um 8:25 PM schrieb Brian E Carpenter: Rolf, I read this draft (the -00 version) recently, since I'm co-author of draft-ietf-anima-grasp, which relies heavily on link-local multicast. I did find it useful, although I didn't in the end change anything as a result. Should you mention the MSEC work and RFC 5374 in particular? Regards Brian Carpenter On 01/11/2016 03:08, Rolf Winter wrote: Hi, Apologies, but I screwed up the draft naming convention and just uploaded the 00 and a 01 version with correct naming. The 00 version is the one that was adopted by the WG, the 01 version now addresses the comments made by Eliot and Stephane. Sorry for the confusion. Best, Rolf Am 10/31/16 um 3:05 PM schrieb internet-dra...@ietf.org: A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Area Working Group of the IETF. Title : Privacy considerations for IP broadcast and multicast protocol designers Authors : Rolf Winter Michael Faath Fabian Weisshaar Filename: draft-ietf-intarea-broadcast-consider-01.txt Pages : 10 Date: 2016-10-31 Abstract: A number of application-layer protocols make use of IP broadcasts or multicast messages for functions like local service discovery or name resolution. Some of these functions can only be implemented efficiently using such mechanisms. When using broadcasts or multicast messages, a passive observer in the same broadcast/ multicast domain can trivially record these messages and analyze their content. Therefore, broadcast/multicast protocol designers need to take special care when designing their protocols. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-intarea-broadcast-consider/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-intarea-broadcast-consider-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-intarea-broadcast-consider-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
