Re: Last Call: draft-farrell-decade-ni-07.txt (Naming Things with Hashes) to Proposed Standard
Hello Stephen, others, On 2012/06/23 6:20, Stephen Farrell wrote: Hi All, I went back through the IETF LC comments and think that we've resolved them all on the list and have the changes in this version [1] of the draft, with the possible exception of those below. The issues raised but not so far obviously resolved on the list were I think: 1) inclusion of content type 2) nih as a URI scheme or not For (1) this version includes ct= in draft-farrell-decade-ni (the only changes to draft-hallambaker-decade-ni-params [2] made so far are those that flow from moving that text), so I'd hope that this version resolves that but would welcome feedback on the new text from folks who commented. I'd hope it should be ok, modulo some text tweaks. For (2) we've left nih in as a URI scheme in this version. We're still in favour of keeping it that way and have added some language about why its there and is done like that. I'm guessing that Martin at least won't be happy (but who knows;-), so again comments are welcome as to whether the new text helps or not. When reading your explanations, I had hoped that there would be some text along the lines of different use case that would really explain why two separate schemes are necessary. For example something similar to what Graham was mentioning at http://www.ietf.org/mail-archive/web/ietf/current/msg73760.html, which I understand is similar to what I mentioned as fingerprints in our discussion. Unfortunately, what I find is the following: The justification for using a URI scheme for this is that that might help a user agent for the speaker to better display the value, or perhaps if there was some use-case for a machine to speak the value. So we are creating a new URI scheme because *perhaps* there is a use case? Or because it *might* help? In the whole discussion, I was always ready to accept that there are different use cases, assuming that they could be clearly explained. I'm really wondering why this is so difficult. If these use cases really exist, it shouldn't be that difficult, and it shouldn't sound so vague, or should it? I'm not necessarily blaming you, but between you, your coauthors, and the WG that apparently proposed this, it shouldn't be that hard to come up with a better and more definite explanation than the sentence above. We do not include the query string since there is no way to ensure that its value might be spoken unambiguously, and similarly for the authority, where e.g. internationalised forms of domain name could not be usefully spoken. This leaves the hash value as the only part of the ni URI that we feel can be usefully included. But since speakers or listeners (or speech recognition) may err, we also include a check-digit to catch common errors. It is really strange to assume that text-to-speech software would work for English (or ASCII in general), but not for other scripts or languages. Sure, the level of text-to-speech software may not be exactly the same for each script and each language, but that's no reason to prohibit a domain name. There are definitely millions of domain names in e.g. Chinese or Japanese or Russian,... that can be spoken and re-typed quite unambiguously, and that users would have much less problems with than a long string of hex digits. (And we would still have the check digit, anyway.) On the other hand, it is quite possible to create domain names with ASCII/English that neither humans nor text-to-speech engines will be able to pronounce right. Regards, Martin. But in the end we'll go with Barry's consensus call on this if he judges that we're in the rough, rather than the folks who've commented on this topic. In that case I'll put out a version with no nih scheme and the human speakable format as just a textual convention (with a check-digit, which'd be plain odd IMO, the uri scheme is the right idea really:-) Please let me know if I've missed addressing anything else or if you have any other comments. Cheers, S. [1] http://tools.ietf.org/html/draft-farrell-decade-ni [2] http://tools.ietf.org/html/draft-hallambaker-decade-ni-params (Note: only [1] is in IETF LC...just in case someone's confused about that:-) On 06/04/2012 03:18 PM, The IESG wrote: The IESG has received a request from an individual submitter to consider the following document: - 'Naming Things with Hashes' draft-farrell-decade-ni-07.txt as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-07-02. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines a set of ways to identify a thing using the output from a hash function, specifying URI, URL, binary and human speakable formats for these names. The
Re: Last Call: draft-farrell-decade-ni-07.txt (Naming Things with Hashes) to Proposed Standard
Hi Martin, On 06/25/2012 11:35 AM, Martin J. Dürst wrote: Hello Stephen, others, On 2012/06/23 6:20, Stephen Farrell wrote: Hi All, I went back through the IETF LC comments and think that we've resolved them all on the list and have the changes in this version [1] of the draft, with the possible exception of those below. The issues raised but not so far obviously resolved on the list were I think: 1) inclusion of content type 2) nih as a URI scheme or not For (1) this version includes ct= in draft-farrell-decade-ni (the only changes to draft-hallambaker-decade-ni-params [2] made so far are those that flow from moving that text), so I'd hope that this version resolves that but would welcome feedback on the new text from folks who commented. I'd hope it should be ok, modulo some text tweaks. For (2) we've left nih in as a URI scheme in this version. We're still in favour of keeping it that way and have added some language about why its there and is done like that. I'm guessing that Martin at least won't be happy (but who knows;-), so again comments are welcome as to whether the new text helps or not. When reading your explanations, I had hoped that there would be some text along the lines of different use case that would really explain why two separate schemes are necessary. For example something similar to what Graham was mentioning at http://www.ietf.org/mail-archive/web/ietf/current/msg73760.html, which I understand is similar to what I mentioned as fingerprints in our discussion. Unfortunately, what I find is the following: The justification for using a URI scheme for this is that that might help a user agent for the speaker to better display the value, or perhaps if there was some use-case for a machine to speak the value. So we are creating a new URI scheme because *perhaps* there is a use case? Or because it *might* help? In the whole discussion, I was always ready to accept that there are different use cases, assuming that they could be clearly explained. I'm really wondering why this is so difficult. If these use cases really exist, it shouldn't be that difficult, and it shouldn't sound so vague, or should it? I'm not necessarily blaming you, but between you, your coauthors, and the WG that apparently proposed this, it shouldn't be that hard to come up with a better and more definite explanation than the sentence above. IMO the use-case is clear, and is stated in the first sentence of section 7. I believe that Graham got the use-case, and accepted that its different from ni URIs, but was questioning the need for nih to be a uri scheme. He can confirm or refute that himself I guess, but quoting his mail [1] (just before the one you reference): I can see that there are distinct use-cases here, and I think you have reasonable grounds for not wanting to combine them. [1] http://www.ietf.org/mail-archive/web/ietf/current/msg73758.html Maybe the language I added for why we want nih as a uri scheme is not sufficiently clear, or isn't convincing, but that's a different argument. We do not include the query string since there is no way to ensure that its value might be spoken unambiguously, and similarly for the authority, where e.g. internationalised forms of domain name could not be usefully spoken. This leaves the hash value as the only part of the ni URI that we feel can be usefully included. But since speakers or listeners (or speech recognition) may err, we also include a check-digit to catch common errors. It is really strange to assume that text-to-speech software would work for English (or ASCII in general), but not for other scripts or languages. Sure, the level of text-to-speech software may not be exactly the same for each script and each language, but that's no reason to prohibit a domain name. There are definitely millions of domain names in e.g. Chinese or Japanese or Russian,... that can be spoken and re-typed quite unambiguously, and that users would have much less problems with than a long string of hex digits. (And we would still have the check digit, anyway.) On the other hand, it is quite possible to create domain names with ASCII/English that neither humans nor text-to-speech engines will be able to pronounce right. The point is that we only leave in the ascii-hex. The goal being to reduce this to something that can be unambiguously spoken, and I think ascii-hex is about as close as one can get to that. Anything else brings additional ambiguity and hence is left out. Its true that the machine-reading/recognition bit is speculative though, but I don't think its much of a leap, nor is it really crucial to the argument. Cheers, S. Regards, Martin. But in the end we'll go with Barry's consensus call on this if he judges that we're in the rough, rather than the folks who've commented on this topic. In that case I'll put out a version with no nih scheme and the human speakable
Re: [nfsv4] Gen-ART LC review of draft-ietf-nfsv4-federated-fs-admin-11 (fwd)
comments inline On 6/20/12 11:53 AM, James Lentini jlent...@netapp.com wrote: Below is the Gen-ART review comments for the FedFS admin protocol. -james -- Forwarded message -- Date: Tue, 19 Jun 2012 11:31:42 -0400 From: Richard L. Barnes rbar...@bbn.com To: ietf@ietf.org, The IESG i...@ietf.org, draft-ietf-nfsv4-federated-fs-ad...@tools.ietf.org, gen-...@ietf.org Subject: Gen-ART LC review of draft-ietf-nfsv4-federated-fs-admin-11 I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-nfsv4-federated-fs-admin-11 Reviewer: Richard Barnes Review Date: Jun-19-2012 IETF LC End Date: Not known IESG Telechat date: Jun-28-2012 Summary: Almost ready, couple of issues MAJOR: 4. / 7. This protocol allows for the provisioning of security information as part of the FedFsNsdbParams, in the form of a certificate to be used in verifying a TLS server certificate. There are two notable issues with how the document does this now: 1. Section 4 does not adequately specify how the certificate in the FedFsNsdbParams should be used in the verification process. Is it to be used as a trust anchor, so that any subordinate certificate is considered valid? Or perhaps it is to be matched against the end-entity certificate. In either case, it seems like it would be sufficient to provision a certificate fingerprint (or even a public key fingerprint) instead of the whole certificate. 2. In the security considerations, the document should discuss the implications of provisioning trust information in this way (depending on how it is used), and any requirements for security mechanisms to be used in these cases. I'm going to have to work with the rest of the group to answer this one. MINOR: 2. It's not clear what the difference is between utf8string_cs and utf8string_cis. Should you mention at some point that these MUST be UTF-8, even though the XDR won't enforce that? (Say, at the beginning of Section 4?) Argh, we did away with utf8string_cs and utf8string_cis in 3530bis. utf8string_cis should be utf8val_REQUIRED4 utf8string_cs should be ascii_REQUIRED4 In 3530bis, these are defined as: typedef :opaque :utf8string:UTF-8 encoding for strings. typedef :utf8string:utf8_expected:String expected to be UTF-8 but no validation typedef :utf8string:utf8val_RECOMMENDED4:String SHOULD be sent UTF-8 and SHOULD be validated typedef :utf8string:utf8val_REQUIRED4:String MUST be sent UTF-8 and MUST be validated typedef :utf8string:ascii_REQUIRED4:String MUST be sent as ASCII and thus is automatically UTF-8 I'll change the types and there is already some text pointing the reader to Chapter 12 of 3530bis. 3. It's not clear to me how FEDFS_ERR_PERM differs from FEDFS_ERR_ACCESS. I don't see it called out for use anywhere in the procedure calls. Perhaps this is a legacy of prior versions that should be deleted? This is inherited from the base NFSv4.0 documentation and also NFSv3. It is also the difference between EPERM and EACCES. (see http://www.wlug.org.nz/EACCES) 13.1.6.1. NFS4ERR_ACCESS (Error Code 13) Indicates permission denied. The caller does not have the correct permission to perform the requested operation. Contrast this with NFS4ERR_PERM (Section 13.1.6.2), which restricts itself to owner or privileged user permission failures. 13.1.6.2. NFS4ERR_PERM (Error Code 1) Indicates requester is not the owner. The operation was not allowed because the caller is neither a privileged user (root) nor the owner of the target of the operation. EDITORIAL: 3. The definition of FEDFS_ERR_LOOP isn't actually related to looping. It seems like this should either detect a loop (e.g., via a repeated name), or be renamed something like FEDFS_ERR_TOOMANYREFERS. This has its roots in a Linux error code: As I recall this error is supposed to be returned when fedfsd is passed a pathname that contains too many symlinks. The equivalent errno on Linux is called ELOOP. We are striving to maintain parity. 4. The port is the NSDB transport port for the LDAP interface Suggest rewording to clarify that this is an LDAP/TCP port (I initially wondered if other transports could be used), e.g.: The port value in the FedFsNsdbName indicates the LDAP port on the NSDB Thanks, we've been struggling with this issue, I'll take your suggested change here. ___ nfsv4 mailing list nf...@ietf.org https://www.ietf.org/mailman/listinfo/nfsv4
Re: [dhcwg] Last Call: draft-ietf-geopriv-dhcp-lbyr-uri-option-15.txt (Dynamic Host Configuration Protocol (DHCP) IPv4 and IPv6 Option for a Location Uniform Resource Identifier (URI)) to Proposed S
On Jun 22, 2012, at 3:59 PM, Alissa Cooper wrote: My understanding is that the option is encoded this way both for extensibility and because the Valid-For parameter is solely a property of the URI. Surely this is not the only instance of a DHCP option with a sub-option? What's in the draft is not suboptions—it's a whole special format requiring new code on all servers that implement it. Suboptions don't exist in DHCPv6—just encapsulations of regular options, which I don't think make sense here either. It may have been before I was paying attention, but I get the impression that related ground has already been trod in DHC, given that it also came up in GEOPRIV. http://www.ietf.org/mail-archive/web/geopriv/current/msg08451.html When the topic of suboptions first came up, it was because I proposed them as an alternative to a complicated internal option structure with lots of special code required in the server to implement. But given that only one Location URI option is allowed, there's no need for suboptions. I'm not sure the additional text is necessary given that there is an entire paragraph explaining considerations for servers in setting the Valid-For value. Furthermore, I don't see how potential loss of service is possible. We're talking about a URI with an expiration. When it expires, location recipients will no longer have access to the client's location, but it otherwise doesn't affect recipients' ability to use any service whatsoever. You're right—don't know how I missed that. Section 3.2 suggests that options shouldn't contain certain potentially harmful values, but this is a toothless restriction, since an attacker can simply ignore it. In order for it to be effective, Section 3.2 should insist that DHCP clients reject forbidden URI formats. Of course, this too is somewhat toothless, since any list of forbidden URI formats will necessarily fail to mention any future potentially harmful URIs that could arise. It would be better to list which URIs _are_ permitted, and require the client to reject any URI that is not permitted. The document is already set up to do this, but doesn't _actually_ do it, so fixing this should be quite easy. In 3.3, I suggest replacing the following: This section specifies which URI types are acceptable as a location URI scheme (or type) for this DHCP Option: with URIs carried by this DHCP Option MUST have one of the following URI schemes: That's just as toothless. Unless the client MUST reject these options, it MAY accept them.
Re: Proposing to create an IETF WG in the general area
Hi Tidd and All, The General Area WGs focus on IETF processes and policies, I don't think projects are done there, So then would this WG also be an incubator for projects? The IETF-WG I propose is only to do with IETF processes and policies (procedures, and best practices), not incubator projects, All organisations in the world have defined Business Information System (BIS) that organises its procedure-policy, information and processes. In IETF we have the BIS as well, but I don't see a clear focused group (like in other organisation) on that updates/follow-ups on the BIS for the future. Other organisation have a management committee for this issue of procedure-updates. Therefore, a WG for this purpose is necessary for two things 1) The WG job is only to follow up with policy issues and if there is a need for update 2) so that when a memebr wants to submit a I-D for to update/replace a policy I can submit to IETF and a focused WG. Please advise or provide your comments, AB === From: tglassey tglassey at earthlink.net To: ietf at ietf.org Date: Sun, 24 Jun 2012 06:22:53 -0700 Gen Area groups also functioned as reception gateways for projects too meaning that the WG Manager in this group would be a lobbyist as well in passing new projects to other WG's once set up. So then would this WG also be an incubator for projects? Todd
RFC 6640 on IETF Meeting Attendees' Frequently Asked (Travel) Questions
A new Request for Comments is now available in online RFC libraries. RFC 6640 Title: IETF Meeting Attendees' Frequently Asked (Travel) Questions Author: W. George Status: Informational Stream: IETF Date: June 2012 Mailbox:wesley.geo...@twcable.com Pages: 13 Characters: 27610 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-george-travel-faq-05.txt URL:http://www.rfc-editor.org/rfc/rfc6640.txt This document attempts to provide a list of the frequently asked questions (FAQs) posed by IETF meeting attendees regarding travel logistics and local information. It is intended to assist those who are willing to provide local information, so that if they wish to pre-populate answers to some or all of these questions either in the IETF wiki or a meeting-specific site, they have a reasonably complete list of ideas to draw from. It is not meant as a list of required information that the host or Secretariat needs to provide; it merely serves as a guideline. This document is not an Internet Standards Track specification; it is published for informational purposes. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC
RFC 6641 on Using DNS SRV to Specify a Global File Namespace with NFS Version 4
A new Request for Comments is now available in online RFC libraries. RFC 6641 Title: Using DNS SRV to Specify a Global File Namespace with NFS Version 4 Author: C. Everhart, W. Adamson, J. Zhang Status: Standards Track Stream: IETF Date: June 2012 Mailbox:everh...@netapp.com, and...@netapp.com, jiayi...@google.com Pages: 11 Characters: 24047 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-nfsv4-federated-fs-dns-srv-namespace-13.txt URL:http://www.rfc-editor.org/rfc/rfc6641.txt The NFS version 4 (NFSv4) protocol provides a mechanism for a collection of NFS file servers to collaborate in providing an organization-wide file namespace. The DNS SRV Resource Record (RR) allows a simple way for an organization to publish the root of its file system namespace, even to clients that might not be intimately associated with such an organization. The DNS SRV RR can be used to join these organization-wide file namespaces together to allow construction of a global, uniform NFS file namespace. [STANDARDS-TRACK] This document is a product of the Network File System Version 4 Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC
BCP 178, RFC 6648 on Deprecating the X- Prefix and Similar Constructs in Application Protocols
A new Request for Comments is now available in online RFC libraries. BCP 178 RFC 6648 Title: Deprecating the X- Prefix and Similar Constructs in Application Protocols Author: P. Saint-Andre, D. Crocker, M. Nottingham Status: Best Current Practice Stream: IETF Date: June 2012 Mailbox:psain...@cisco.com, dcroc...@bbiw.net, m...@mnot.net Pages: 13 Characters: 28393 See Also: BCP0178 I-D Tag:draft-ietf-appsawg-xdash-05.txt URL:http://www.rfc-editor.org/rfc/rfc6648.txt Historically, designers and implementers of application protocols have often distinguished between standardized and unstandardized parameters by prefixing the names of unstandardized parameters with the string X- or similar constructs. In practice, that convention causes more problems than it solves. Therefore, this document deprecates the convention for newly defined parameters with textual (as opposed to numerical) names in application protocols. This memo documents an Internet Best Current Practice. This document is a product of the Applications Area Working Group Working Group of the IETF. BCP: This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC
RFC 6650 on Creation and Use of Email Feedback Reports: An Applicability Statement for the Abuse Reporting Format (ARF)
A new Request for Comments is now available in online RFC libraries. RFC 6650 Title: Creation and Use of Email Feedback Reports: An Applicability Statement for the Abuse Reporting Format (ARF) Author: J. Falk, M. Kucherawy, Ed. Status: Standards Track Stream: IETF Date: June 2012 Mailbox:none, superu...@gmail.com Pages: 15 Characters: 35273 Updates:RFC5965 I-D Tag:draft-ietf-marf-as-16.txt URL:http://www.rfc-editor.org/rfc/rfc6650.txt RFC 5965 defines an extensible, machine-readable format intended for mail operators to report feedback about received email to other parties. This applicability statement describes common methods for utilizing this format for reporting both abuse and authentication failure events. Mailbox Providers of any size, mail-sending entities, and end users can use these methods as a basis to create procedures that best suit them. Some related optional mechanisms are also discussed. [STANDARDS-TRACK] This document is a product of the Messaging Abuse Reporting Format Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC
RFC 6652 on Sender Policy Framework (SPF) Authentication Failure Reporting Using the Abuse Reporting Format
A new Request for Comments is now available in online RFC libraries. RFC 6652 Title: Sender Policy Framework (SPF) Authentication Failure Reporting Using the Abuse Reporting Format Author: S. Kitterman Status: Standards Track Stream: IETF Date: June 2012 Mailbox:sc...@kitterman.com Pages: 8 Characters: 15373 Updates:RFC4408 I-D Tag:draft-ietf-marf-spf-reporting-11.txt URL:http://www.rfc-editor.org/rfc/rfc6652.txt This memo presents extensions to the Abuse Reporting Format (ARF) and Sender Policy Framework (SPF) specifications to allow for detailed reporting of message authentication failures in an on-demand fashion. This memo updates RFC 4408 by providing an IANA registry for SPF modifiers. [STANDARDS-TRACK] This document is a product of the Messaging Abuse Reporting Format Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC
Protocol Action: 'Media Type Specifications and Registration Procedures' to Best Current Practice (draft-ietf-appsawg-media-type-regs-14.txt)
The IESG has approved the following document: - 'Media Type Specifications and Registration Procedures' (draft-ietf-appsawg-media-type-regs-14.txt) as Best Current Practice This document is the product of the Applications Area Working Group. The IESG contact persons are Barry Leiba and Pete Resnick. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-appsawg-media-type-regs/ Technical Summary This document defines procedures for the specification and registration of media types for use in HTTP, MIME and other Internet protocols. Working Group Summary The document was developed by seasoned experts in media types, and was preceded by significant discussion. The process has been mostly smooth, but for a great deal of wordsmithing and then picking nits in the smithed words. That process could go on forever, and sometimes seems to. Document Quality The document updates media type registration procedures based on experience since the publication of RFC4288. The procedures created there and in its antecedent have been around for a long time; this document merely refines them. The aforementioned wordsmithing has given us a solid document. Personnel Murray Kucherawy is the Document Shepherd. Barry Leiba is the responsible Area Director. RFC Editor notes: Section 3.1 OLD The first procedure is used for registering registrations from IETF Consensus documents NEW The first procedure is used for registrations from IETF Consensus documents
Protocol Action: 'Source Ports in ARF Reports' to Proposed Standard (draft-kucherawy-marf-source-ports-05.txt)
The IESG has approved the following document: - 'Source Ports in ARF Reports' (draft-kucherawy-marf-source-ports-05.txt) as Proposed Standard This document has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG contact person is Barry Leiba. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-kucherawy-marf-source-ports/ Technical Summary The information included in an ARF report has not included the source port number on which a message was received. As RFC 6032 notes, the increasing use of NAT on IPv4 networks means that the port number for a connection is often needed to determine the actual host. This draft adds a new report field for the port number. Working Group Summary This individual submission was briefly disucssed at the MARF meeting at IETF 83 and has had some discussion on the MARF mailing list. Because it is simple and uncontroversial, and MARF is scheduled to close once its existing documents are done, it wasn't worth the hassle of keeping MARF open to handle it. Document Quality The quality is good. It's a tiny tweak to ARF which I added to my reporting scripts in about 15 minutes. No formal reviews are required. Personnel John Levine is the Document Shepherd. Barry Leiba is the Responsible Area Director.
Document Action: 'Promoting Compliance with Intellectual Property Rights (IPR) Disclosure Rules' to Informational RFC (draft-polk-ipr-disclosure-05.txt)
The IESG has approved the following document: - 'Promoting Compliance with Intellectual Property Rights (IPR) Disclosure Rules' (draft-polk-ipr-disclosure-05.txt) as Informational RFC This document has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG contact person is Russ Housley. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-polk-ipr-disclosure/ Technical Summary The disclosure process for intellectual property rights (IPR) in documents produced within the IETF stream is essential to the accurate development of community consensus. However, this process is not always followed by IETF participants. Regardless of the cause or motivation, noncompliance with IPR disclosure rules can delay or even derail completion of IETF specifications. This document describes some strategies for promoting compliance with the IPR disclosure rules. These strategies are primarily intended for use by area directors, working group chairs, and working group secretaries. Working Group Summary This document is not the product of any IETF WG. Document Quality The document has been reviewed in the IETF mail list during Last Call. The authors received actionable feedback from Stephan Wenger and Subramanian Moonesamyby, and both of them expressed satisfaction with changes that were made to resolve their issues. Personnel Russ Housley is the responsible AD.
Results of IETF-conflict review for draft-despres-6a44-02.txt
The IESG has completed a review of draft-despres-6a44 consistent with RFC5742. This review is applied to all non-IETF streams. The IESG has no problem with the publication of 'Native IPv6 Behind NAT44 CPEs (6a44)' draft-despres-6a44-02.txt as an Experimental RFC. The IESG would also like the RFC-Editor to review the comments in the datatracker (http://datatracker.ietf.org/doc/draft-despres-6a44/) related to this document and determine whether or not they merit incorporation into the document. Comments may exist in both the ballot and the history log. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-despres-6a44/ The process for such documents is described at http://www.rfc-editor.org/indsubs.html Thank you, The IESG Secretary Technical Summary In customer sites having IPv4-only CPEs, Teredo provides a last resort IPv6 connectivity [RFC4380] [RFC5991] [RFC6081]. However, because it is designed to work without involvement of Internet service providers, it has significant limitations (connectivity between IPv6 native addresses and Teredo addresses is uncertain; connectivity between Teredo addresses fails for some combinations of NAT types). 6a44 is a complementary solution that, being base on ISP cooperation, avoids these limitations. 6a44 uses specific prefixes assigned by local ISPs (rather than the anycast address used by Teredo, an evolution similar to that from 6to4 to 6rd). The specification is complete enough for actual deployment, including with independently written codes. Working Group Summary This document is in the Independent Stream, and is under RFC 5742 review by the IESG. Document Quality Ralph Droms reviewed the document according to RFC 5742 and recommends responding that the IESG has no problem with the publication of 'Native IPv6 Behind NAT44 CPEs (6a44)' draft-despres-6a44-01 as an Experimental RFC. Personnel Ralph Droms is managing the RFC 5742 review of this document. RFC Editor Note The IESG has concluded that this work is related to IETF work done in WGs behave, softwire and sunset4, but this relationship does not prevent publishing.
