For that reason, I don't think we should get too hung up about what 6lowpan is now considered to mean. In other words - let's publish.
Robert On 11/08/2011 9:04 AM, Pascal Thubert (pthubert) wrote:
Hi Megan; I do 100% agree with Ralph here. I'd prefer that we make that change before publish. Apart from that, I'm perfectly happy with the text as it stands. Cheers, Pascal-----Original Message----- From: Ralph Droms (rdroms) Sent: Wednesday, August 10, 2011 8:15 PM To: Pascal Thubert (pthubert) Cc: Ralph Droms (rdroms); Megan Ferguson; Carsten Bormann; 6lowpan;RFCEditor; [email protected] Subject: Re: [6lowpan] [ADs] AUTH48 [MF]: RFC 6282<draft-ietf-6lowpan-hc-15.txt> Following up on Pascal's observation, I looked through the entire docforoccurrences of "6lopwan". In my opinion, all of those occurrencescould bereplaced with "IEEE802.15.4-based network"; in some cases s/the 6lowpan/an IEEE802.15.4-based network/ In either case, note thelower-case "network". Not meaning to delay the publication process further, but I think weshouldtake a second to consider consistency... - Ralph On Aug 9, 2011, at 1:04 PM 8/9/11, Pascal Thubert (pthubert) wrote:Hello Megan I think that for consistency: LOWPAN_HC1 and LOWPAN_HC2 are insufficient for most practical usesofIPv6 in 6LoWPANs. LOWPAN_HC1 is most effective for link-local Should also become LOWPAN_HC1 and LOWPAN_HC2 are insufficient for most practical usesofIPv6 in IEEE 802.15.4-Based Networks. LOWPAN_HC1 is most effective for link-local Don't you think? Pascal-----Original Message----- From: Megan Ferguson [mailto:[email protected]] Sent: Tuesday, August 09, 2011 5:02 PM To: Carsten Bormann; Ralph Droms (rdroms); Pascal Thubert(pthubert)Cc: 6lowpan; RFC Editor; [email protected] Subject: Re: [6lowpan] [ADs] AUTH48 [MF]: RFC 6282<draft-ietf-6lowpan-hc-15.txt> Carsten, Pascal, and *ADs, Thank you for your reply. We have updated the title as requested.Pleasenote that we have also updated the expansion of 6LoWPAN (in thetext)tomatch that in the title of RFC 4919. Additionally, we have updatedthe shorttitle that appears in the running header of the document (this isbestreviewed in the text file below). Please review and approve theseupdatesor let us know if a different approach in either of theseadditionalupdateswould be preferable. http://www.rfc-editor.org/authors/rfc6282-lastdiff.html The text, XML, and comprehensive diff files are viewable at: http://www.rfc-editor.org/authors/rfc6282.txt http://www.rfc-editor.org/authors/rfc6282.xml http://www.rfc-editor.org/authors/rfc6282-diff.html Note that it may be necessary for you to refresh your browser toviewthe most recent version of the document. Please review thedocumentcarefully to ensure satisfaction as we do not make changes once the document has been published as an RFC. Upon careful review, please contact us with any further updates orwithyour approval of the document in its current form. For the AUTH48 status of this document, please see: http://www.rfc-editor.org/auth48/rfc6282 Thank you. RFC Editor/mf On Aug 8, 2011, at 1:44 PM, Carsten Bormann wrote:OK, I have reread all the messages, and I'm now ready to declare a(rough)consensus forCompression Format for IPv6 Datagrams over IEEE 802.15.4-basedNetworks(with an ever so slight edge for the -based, which is differentfromRFC4944, but "Datagrams" is different, too).While there were a number of voices for keeping 6LoWPAN in thetitle(asin RFC 4919), there did not seem to be consensus for that.I apologize for holding up this RFC for so long for what is prettymuch abikeshed color issue.And, yes, I'm slowly getting back to IETF work, and will try tostart poppingthe stack.Gruesse, Carsten_______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
