Re: [Gen-art] Gen-art reiew of draft-ietf-rohc-ipsec-extensions-hcoipsec-05
Hi.
This seems good to me. One minor point on the ASN.1: I think the extra
'rohc' piece should it be specified as 'OPTIONAL' so that not it doesn't
have to be in every implementation - and should it come after the tunnel
params as this change will alter the OID of tunnel params as it stands
(if my understanding of ASN.1 is right)?
Thanks.
Elwyn
Ertekin, Emre [USA] wrote:
Hi Elwyn,
SPD additions:
In Section 2.1 some additional fields to be added to the SPD
Processing component are described informally. RFC 4301 which has
the
unmodified version of the Processing component also has a formal
ASN.1
description. I think this document needs an updated ASN.1
desciption
also.
Further the description talks about adding 'processing info' fields
if
the
'processing info field is set to PROTECT'. Although this partly
reflects the
wording in the body of RFC 4301, it is rather confusing when looking
at
the
ASN.1. The wording of para 3 of S2.1 might be better as:
If the SPD entry is an IPsecEntry (to PROTECT traffic) then the
Processing
item of the IPsecEntry must be extended with the following items:
On refelection, I agree that using IPsecEntry in s2.1 wouldn't be
appropriate. However I think the wording could still be improved.
Retry:
If the processing action associated with the selector sets is
PROTECT, then the processing info must be
extended with the following ROHC channel parameters:
OK; sounds good!
A while back, we were thinking of adding ASN.1 notation to the
draft...however we opted not to. This is because Appendix C in RFC
4301 is only an example ASN.1 definition of a SPD and is referred to as
merely illustrative. Since our extensions would've expanded
upon/augmented this non-normative text, we decided to leave it out.
Sure, it is illustrative, but it also seems to have specified a fully
qualified OID. This indicates to me that at least some people may be
using this as an access mechanism for the SPD. In that case formally
specifying the ASN.1 would be highly desirable even if it is not
normative. Doubtless there are other people who know if the SPD is
accessed this way (e.g. as a MIB) even if I don't.
OK. We developed the ASN.1 representation of the ROHC parameters and plan to
incorporate it as an Appendix to the draft. The text reads as follows:
Appendix A. ASN.1 representation for ROHCoIPsec
This appendix is included as an additional way to describe the
ROHCoIPsec parameters that are included in the IPsec SPD. It uses
portions of the ASN.1 syntax provided in Appendix C of RFC 4301
[IPSEC]. In addition, several new structures are defined.
This syntax has been successfully compiled. However, it is merely
illustrative and need not be employed in an implementation to achieve
compliance.
The Processing data structure, defined in Appendix C of RFC 4301,
is augmented to include a ROHC parameters element as follows:
Processing ::= SEQUENCE {
extSeqNum BOOLEAN, -- TRUE 64 bit counter, FALSE 32 bit
seqOverflow BOOLEAN, -- TRUE rekey, FALSE terminate audit
fragCheck BOOLEAN, -- TRUE stateful fragment checking,
-- FALSE no stateful fragment checking
lifetimeSALifetime,
spi ManualSPI,
algorithms ProcessingAlgs,
rohcRohcParams,
tunnel TunnelOptions OPTIONAL
}
The following data structures describe these ROHC parameters:
RohcParams ::= SEQUENCE {
rohcEnabled BOOLEAN, -- TRUE, hdr compression is enabled
-- FALSE, hdr compression is disabled
maxCID INTEGER (0..16383),
mrruINTEGER,
profilesRohcProfiles,
rohcIntegAlgRohcIntegAlgs,
rohcIntegICVLength INTEGER
}
RohcProfiles ::= SET OF RohcProfile
RohcProfile ::= INTEGER {
rohcv1-rtp (1),
rohcv1-udp (2),
rohcv1-esp (3),
rohcv1-ip(4),
rohcv1-tcp (6),
rohcv1-rtp-udpLite (7),
rohcv1-udpLite (8),
rohcv2-rtp (257),
rohcv2-udp (258),
rohcv2-esp (259),
rohcv2-ip (260),
rohcv2-rtp-udpLite (263),
rohcv2-udpLite (264)
}
RohcIntegAlgs ::= SEQUENCE {
algorithm RohcIntegAlgType,
parameters ANY -- DEFINED BY algorithm -- OPTIONAL }
RohcIntegAlgType ::= INTEGER {
none(0),
[Gen-art] re-review of draft-ietf-pkix-authorityclearanceconstraints-03.txt
I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-pkix-authorityclearanceconstraints-03.txt Reviewer: Francis Dupont Review Date: 2009-08-10/2009-11-30 IETF LC End Date: 2009-08-14 IESG Telechat date: unknown Summary: Almost Ready Comments: the previous major issue was the I-D is too hard to read. All minor issues and NITs were addressed but I read the document enough times to be too familar with it so I can't say if the major issue is solved (but IMHO this version is already far better). So I put an almost and leave the assessment to someone else. Regards francis.dup...@fdupont.fr ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] My (Richard) comments to the Gen-ART review of draft-ietf-capwap-base-mib-06
Hi, All : Please check my comments identified by the [Richard]. To David: Thanks a lot. The important open issues that need to be resolved are tagged with [*]. [*] Intended document status is now Informational. That needs to be changed on the title page, but more importantly, someone (draft shepherd?) should double-check whether the requested IANA allocations are appropriate for an Informational document. If there's a problem here, the IESG should be warned that a process exception may be needed, as I think the allocations are necessary for this draft. [Richard] Margaret or Dan, please confirm it. [*] I see lots of editorial problems in the text prior to the MIB definitions, most of which are not called out in this review. I strongly suggest an editorial pass by a native speaker of English prior to IESG Review. Here's an example from Section [Richard] Margaret or Dan, please consider how to handle it. For the text, I can't do better job than a native speaker of English:( 5.6 - the use of the word conception is incorrect in this phrase: the protocol of [RFC5416] defines WLAN conception A better word would be creation. [Richard] Hi, David. Whether management instead of creation is better? Terminology section: - Add a definition of PHY, it's undefined in this document. [Richard] It is a very general conception. I checked the RFC5415, it does not give the definition of PHY. How about: physical layer (PHY) in the place where it first appears? I am ok with adding a definition of PHY if it is a better solution. - Add a definition of WLAN, while it's defined elsewhere, WLAN is a crucial concept for this draft and hence needs a definition here. [Richard] I am ok. - The definition of station (STA) is sufficiently general to include WTPs. Was that intended? [Richard] I got the definition of station (STA) and WTP from RFC5415. Section 5.1 should explain the division of management of a WTP between the actual CAPWAP protocol and this MIB. The first bullet creates this confusion, and that bullet is not consistent with the first bullet in 5.4. That lack of consistency should be corrected in addition to providing the explanation. [Richard] I did not get the point. Kindly give more input Section 5.4: The ifIndex [RFC2863] is used as a common handler I don't think it's a handler. The ifIndex is actually an index. [Richard] How about use index instead of handler. [*] The text in Section 5.7 attempts to modify RFC 5415. That's not a good idea for an Informational document. It is ok to say that if the additional requirements are not followed, this MIB will not be useful or usable. [Richard] The WG already made the consensus on it after IETF 75th, and the WG agree to use the following text. The section 4.6.40 [RFC5415] does not clarify that the WTP's Base MAC address MUST be included in the WTP Board Data message element. This is a known errata item and assumed to be fixed in future by the editors of the RFC5415. [*] Why is Section 9 (CAPWAP Message Element Extension) in a MIB draft? MIB drafts generally do not make changes to the protocol that they provide management for. This section, and the changes in Section 5.7 ought to be in a separate draft that could be standards track. [Richard] Margaret or Dan, please confirm whether it is allowed to have the Message Element Extension in the MIB drafts. The manageable in the current text To enable CAPWAP protocol timers and variables [RFC5415] manageable through CAPWAP protocol is not very clear. Maybe the word viewable is better. How about we use the text To enable CAPWAP protocol timers and variables [RFC5415] viewable on the AC through CAPWAP protocol ? Since the MIB objects (such as capwapBaseAcMaxRetransmit ) corresponding to the CAPWAP protocol timers and variables are optional, whether it is required to add some text in the Section 9 to clarify that the CAPWAP Message Element Extension is optional? Appendix A (change history) should include a request to the RFC Editor to remove it before publication of the RFC. [Richard] It is ok. idnits 2.11.15 found a couple of nits: == The document seems to lack a disclaimer for pre-RFC5378 work, but was first submitted before 10 November 2008. Should you add the disclaimer? (See the Legal Provisions document at http://trustee.ietf.org/license-info for more information.). [Richard] It is ok. == Outdated reference: A later version (-05) exists of draft-ietf-capwap-802dot11-mib-04 [Richard] It is ok. The following recipient(s) could not be reached: chell...@cisco.com on 11/25/2009 7:43 PM The e-mail system was unable to deliver the message, but did not report a specific reason. Check the address and try again. If it still fails, contact your system administrator. sj-inbound-d.cisco.com #5.0.0 smtp; 5.1.0 - Unknown address error 550-'5.1.1
[Gen-art] review of draft-ietf-ccamp-lsp-dppm-10.txt
I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-ietf-ccamp-lsp-dppm-10.txt
Reviewer: Francis Dupont
Review Date: 2009-11-28
IETF LC End Date: 2009-11-23
IESG Telechat date: unknown
Summary: Ready
Major issues: None
Minor issues: too many authors in Authors' Addresses (see below)
Nits/editorial comments:
- the document is heavily cut paste between sections. This makes it
like a MIB document so I have a mixed opinion about whether it is a
good thing: the document is very clear, each part stands by itself,
but it is a bit long and certainly boring to read.
- Abstract page 3: I prefer to get the LSP abbrev introducted
(the Abstract should stand by itself and LSP is not stared by
the RFC Editor as well known/doesn't need expansion)
- TOC page 6:
* extra space in 12. title
* Acknowledgements - Acknowledgments
- Introduction page 8: same concern about LSP (but in this case you can
consider it was introduced in the document title)
- 4.7 page 13 (and 5.7 page 16, 6.7 page 20, 7.7 page 24):
(T2 -T1) - (T2-T1)
- 4.8 page 13 (and 5.8 page 17, 6.8 page 20, 7.8 page 25, 8.8 page 29):
uppper - upper
- 6.6 page 20 (and 7.6 page 23):
Thus, In practice - Thus, in practice
- 8.8 page 29: eg. - e.g.,
- 12 page 39 (title): Bidirectional LSPs - Bidirectional LSPs
- 12.7.2.1 page 42 (first statement):
multiple bidirec... - Multiple bidirec...
- 18 page 49 (title): Acknowledgements - Acknowledgments
- Authors' Addresses:
* add a space after a comma (',' - ', ')
* CN - China (many!)
* Telecommunicaiton - Telecommunication?
* you have too many authors, I suggest to keep the two editors and
to put other authors in a contributors section. Look at the RFC
Editor site about how to do this.
Regards
francis.dup...@fdupont.fr
PS: spelling of Re[sS]erVation in RSVP is not uniform but this happened
12 years ago... too late to fix it.
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] [Capwap] My (Richard) comments to the Gen-ART review of draft-ietf-capwap-base-mib-06
Try chell...@gmail.com dbh -Original Message- From: young [mailto:yo...@h3c.com] Sent: Sunday, November 29, 2009 10:42 PM To: black_da...@emc.com; dperk...@snmpinfo.com; yzh...@fortinet.com; gen-art@ietf.org; m...@lilacglade.org; droma...@avaya.com Cc: cap...@frascone.com Subject: [Capwap] My (Richard) comments to the Gen-ART review of draft-ietf-capwap-base-mib-06 Hi, All : Please check my comments identified by the [Richard]. To David: Thanks a lot. The important open issues that need to be resolved are tagged with [*]. [*] Intended document status is now Informational. That needs to be changed on the title page, but more importantly, someone (draft shepherd?) should double-check whether the requested IANA allocations are appropriate for an Informational document. If there's a problem here, the IESG should be warned that a process exception may be needed, as I think the allocations are necessary for this draft. [Richard] Margaret or Dan, please confirm it. [*] I see lots of editorial problems in the text prior to the MIB definitions, most of which are not called out in this review. I strongly suggest an editorial pass by a native speaker of English prior to IESG Review. Here's an example from Section [Richard] Margaret or Dan, please consider how to handle it. For the text, I can't do better job than a native speaker of English:( 5.6 - the use of the word conception is incorrect in this phrase: the protocol of [RFC5416] defines WLAN conception A better word would be creation. [Richard] Hi, David. Whether management instead of creation is better? Terminology section: - Add a definition of PHY, it's undefined in this document. [Richard] It is a very general conception. I checked the RFC5415, it does not give the definition of PHY. How about: physical layer (PHY) in the place where it first appears? I am ok with adding a definition of PHY if it is a better solution. - Add a definition of WLAN, while it's defined elsewhere, WLAN is a crucial concept for this draft and hence needs a definition here. [Richard] I am ok. - The definition of station (STA) is sufficiently general to include WTPs. Was that intended? [Richard] I got the definition of station (STA) and WTP from RFC5415. Section 5.1 should explain the division of management of a WTP between the actual CAPWAP protocol and this MIB. The first bullet creates this confusion, and that bullet is not consistent with the first bullet in 5.4. That lack of consistency should be corrected in addition to providing the explanation. [Richard] I did not get the point. Kindly give more input Section 5.4: The ifIndex [RFC2863] is used as a common handler I don't think it's a handler. The ifIndex is actually an index. [Richard] How about use index instead of handler. [*] The text in Section 5.7 attempts to modify RFC 5415. That's not a good idea for an Informational document. It is ok to say that if the additional requirements are not followed, this MIB will not be useful or usable. [Richard] The WG already made the consensus on it after IETF 75th, and the WG agree to use the following text. The section 4.6.40 [RFC5415] does not clarify that the WTP's Base MAC address MUST be included in the WTP Board Data message element. This is a known errata item and assumed to be fixed in future by the editors of the RFC5415. [*] Why is Section 9 (CAPWAP Message Element Extension) in a MIB draft? MIB drafts generally do not make changes to the protocol that they provide management for. This section, and the changes in Section 5.7 ought to be in a separate draft that could be standards track. [Richard] Margaret or Dan, please confirm whether it is allowed to have the Message Element Extension in the MIB drafts. The manageable in the current text To enable CAPWAP protocol timers and variables [RFC5415] manageable through CAPWAP protocol is not very clear. Maybe the word viewable is better. How about we use the text To enable CAPWAP protocol timers and variables [RFC5415] viewable on the AC through CAPWAP protocol ? Since the MIB objects (such as capwapBaseAcMaxRetransmit ) corresponding to the CAPWAP protocol timers and variables are optional, whether it is required to add some text in the Section 9 to clarify that the CAPWAP Message Element Extension is optional? Appendix A (change history) should include a request to the RFC Editor to remove it before publication of the RFC. [Richard] It is ok. idnits 2.11.15 found a couple of nits: == The document seems to lack a disclaimer for pre-RFC5378 work, but was first submitted before 10 November 2008. Should you add the disclaimer? (See the Legal Provisions document at http://trustee.ietf.org/license-info for more
[Gen-art] Assignments for Dec 3rd, 2009 Telechat
Hi all, Sorry for the delay in getting this out - the agenda came out late on Friday and I just could not get it done over the weekend. Here's the link to the summary of assignments for the Dec 3rd, 2009 telechat: http://www.softarmor.com/rai/temp-gen-art/reviewers-091203.html With the updated spreadsheets: http://www.softarmor.com/rai/temp-gen-art/gen-art.html http://www.softarmor.com/rai/temp-gen-art/gen-art-by-reviewer.html For your convenience, the review boilerplate template is included below. Note that reviews should ideally be posted to the gen-art mailing list by COB on Tuesday: http://www.alvestrand.no/ietf/gen/art/review-guidelines.html Mary. --- I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: Reviewer: Review Date: IESG Telechat date: 03 Dec 2009 Summary: Major issues: Minor issues: Nits/editorial comments: ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] A *new* batch of IETF LC reviews - 30 Nov 2009
Hi all, Here's the link to the new LC assignments for this week: http://www.softarmor.com/rai/temp-gen-art/reviewers-091126-lc.html The assignments are captured in the spreadsheets: http://www.softarmor.com/rai/temp-gen-art/gen-art.html http://www.softarmor.com/rai/temp-gen-art/gen-art-by-reviewer.html The standard template is included below. Thanks, Mary. --- I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please resolve these comments along with any other Last Call comments you may receive. Document: Reviewer: Review Date: IETF LC End Date: IESG Telechat date: (if known) Summary: Major issues: Minor issues: Nits/editorial comments: ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Gen-ART review of draft-carpenter-renum-needs-work-04
Brian E Carpenter wrote:
Vijay,
Brian: Thanks for attending to my comments. More inline.
I think the difference is that the Java run-time system includes
the ability to automagically prefer v6 or v4. Specifically, the
JDK provides java.net.preferIPv4Stack and java.net.preferIPv6Addresses.
So if the programmer chooses to use FQDNs then the run-time will
act according to those preferences. In C/C++ the programmer has
to implement such preferences with extra logic.
But these -- java.net.preferIPv4Stack and
java.net.preferIPv6Addresses -- are simply networking properties
that the programmer has to remember to set (I am sure they
have sane default values, but regardless, they are attributes
that can be modified by the programmer.)
In much the same vein, someone could write a wrapper around
the C/C++ getaddrinfo() API to prefer IPv4 or IPv6.
I agree that setting properties in Java is much easier than
writing a wrapper around an API, but regardless, it is not the
case that Java is exposing some additional functionality that
C/C++ do not. Java is just packaging the functionality in
an attractive, easy to use manner.
We have quite a few other changes to make following IESG comments,
so there will definitely be a new version.
OK, thank you.
- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
Email: v...@{alcatel-lucent.com,bell-labs.com,acm.org}
Web: http://ect.bell-labs.com/who/vkg/
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Gen-ART review of draft-carpenter-renum-needs-work-04
On 30 Nov 2009, at 12:51 , Vijay K. Gurbani wrote: ...it is not the case that Java is exposing some additional functionality that C/C++ do not. Indeed. That is precisely our point, although phrased in an inverse manner. The more abstracted Java Networking APIs *HIDE* some low-level/ more-specific networking information from application programmers. As with the standard situation in Computer Science, such use of information hiding encourages application programmers to use properly high-level and abstract designs both for their applications and their application protocols. In turn, this tends to make the resulting applications more tolerant of changes to low-level networking details (e.g. changes to an IP address). As our draft is entirely about the issues and limitations of IP renumbering, this is precisely on point and within scope for our draft. As an aside, I'm told that Apple's COCOA APIs (and possibly also some proprietary Microsoft Windows APIs) also engage in significant information hiding, for the same reasons as the more abstract Java networking APIs, and likely with the same benefits. However, those are not open-standard C/C++ networking APIs, but rather platform-specific networking APIs. So they don't make very good examples. The abstracted Java networking APIs are, however, both platform-independent and open-standard, which is why those are particularly good examples for our document. [And yes, I know that some Java instances might contain ugly low-level networking APIs. THese are not commonly used, however, and programmers don't have the equivalent choice of API abstraction in open-standard C/C++ today (at least for platform-independent software) that they do today in open-standard Java. The point is not that one could write bad software. The point is that Java encourages one to write good software by having suitably abstracted APIs as the normal and most commonly used/taught networking APIs. It is a pity that such abstracted APIs were not openly specified by the IETF during the protracted IPv6 process.] Cheers, Ran ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Gen-ART review of draft-carpenter-renum-needs-work-04
Ran Atkinson wrote:
On 30 Nov 2009, at 12:51 , Vijay K. Gurbani wrote:
...it is not the
case that Java is exposing some additional functionality that
C/C++ do not.
Indeed. That is precisely our point, although phrased in an
inverse manner.
I think we are in agreement. The main issue I wanted to
make sure got across is exactly what I wrote previously:
...it is not the case that Java is exposing some additional
functionality that C/C++ do not. Java is just packaging
the functionality in an attractive, easy to use manner.
Any attempts to word-smith this in a manner that does not
give undue advantage to a particular language should be good.
In a certain sense, Java is a language as well as a platform.
Thus, many ideas can be abstracted a bit better that one could
do so in C++. To take an equivalent example, one could just
as well include these IPv4/IPv6 APIs in the C++ boost library
and attain the same level of abstraction as Java does.
Thanks,
- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
Email: v...@{alcatel-lucent.com,bell-labs.com,acm.org}
Web: http://ect.bell-labs.com/who/vkg/
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Gen-art reiew of draft-ietf-rohc-ipsec-extensions-hcoipsec-05
Hi.
Last minute thought... the profile identifiers tie up with the profile
numbers in RFC 4996 and RFC 5225 - it would be worth noting that. I
can't see where the authentication algorithm identifiers tie up with - I
presume there must be some place these various algorithms are specified
for ROHC. It ought to be referenced.
Regards,
Elwyn
Ertekin, Emre [USA] wrote:
Hi Elwyn,
Great. I agree with both of your points. I will make the updates to the draft.
Once I make these changes, I will consider this thread/comment as resolved.
BR,
Emre
-Original Message-
From: Elwyn Davies [mailto:elw...@dial.pipex.com]
Sent: Monday, November 30, 2009 3:08 AM
To: Ertekin, Emre [USA]
Cc: General Area Reviwing Team; Mary Barnes; rohc-...@tools.ietf.org;
rohc-cha...@tools.ietf.org; c...@tzi.org; Christou, Christos [USA]
Subject: Re: Gen-art reiew of draft-ietf-rohc-ipsec-extensions-
hcoipsec-05
Hi.
This seems good to me. One minor point on the ASN.1: I think the
extra
'rohc' piece should it be specified as 'OPTIONAL' so that not it
doesn't
have to be in every implementation - and should it come after the
tunnel
params as this change will alter the OID of tunnel params as it stands
(if my understanding of ASN.1 is right)?
Thanks.
Elwyn
Ertekin, Emre [USA] wrote:
Hi Elwyn,
SPD additions:
In Section 2.1 some additional fields to be added to the SPD
Processing component are described informally. RFC 4301 which has
the
unmodified version of the Processing component also has a formal
ASN.1
description. I think this document needs an updated ASN.1
desciption
also.
Further the description talks about adding 'processing info'
fields
if
the
'processing info field is set to PROTECT'. Although this partly
reflects the
wording in the body of RFC 4301, it is rather confusing when
looking
at
the
ASN.1. The wording of para 3 of S2.1 might be better as:
If the SPD entry is an IPsecEntry (to PROTECT traffic) then the
Processing
item of the IPsecEntry must be extended with the following
items:
On refelection, I agree that using IPsecEntry in s2.1 wouldn't be
appropriate. However I think the wording could still be improved.
Retry:
If the processing action associated with the selector sets is
PROTECT, then the processing info must be
extended with the following ROHC channel parameters:
OK; sounds good!
A while back, we were thinking of adding ASN.1 notation to the
draft...however we opted not to. This is because Appendix C in RFC
4301 is only an example ASN.1 definition of a SPD and is referred to
as
merely illustrative. Since our extensions would've expanded
upon/augmented this non-normative text, we decided to leave it out.
Sure, it is illustrative, but it also seems to have specified a
fully
qualified OID. This indicates to me that at least some people may
be
using this as an access mechanism for the SPD. In that case
formally
specifying the ASN.1 would be highly desirable even if it is not
normative. Doubtless there are other people who know if the SPD is
accessed this way (e.g. as a MIB) even if I don't.
OK. We developed the ASN.1 representation of the ROHC parameters and
plan to incorporate it as an Appendix to the draft. The text reads as
follows:
Appendix A. ASN.1 representation for ROHCoIPsec
This appendix is included as an additional way to describe the
ROHCoIPsec parameters that are included in the IPsec SPD. It uses
portions of the ASN.1 syntax provided in Appendix C of RFC 4301
[IPSEC]. In addition, several new structures are defined.
This syntax has been successfully compiled. However, it is merely
illustrative and need not be employed in an implementation to
achieve
compliance.
The Processing data structure, defined in Appendix C of RFC
4301,
is augmented to include a ROHC parameters element as follows:
Processing ::= SEQUENCE {
extSeqNum BOOLEAN, -- TRUE 64 bit counter, FALSE 32
bit
seqOverflow BOOLEAN, -- TRUE rekey, FALSE terminate
audit
fragCheck BOOLEAN, -- TRUE stateful fragment checking,
-- FALSE no stateful fragment
checking
lifetimeSALifetime,
spi ManualSPI,
algorithms ProcessingAlgs,
rohcRohcParams,
tunnel TunnelOptions OPTIONAL
}
The following data structures describe these ROHC parameters:
RohcParams ::= SEQUENCE {
rohcEnabled BOOLEAN, -- TRUE, hdr compression is
enabled
-- FALSE,
[Gen-art] Gen-ART review of draft-ietf-sasl-gs2-18
I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-sasl-gs2-18 Reviewer: Spencer Dawkins Review Date: 2009-11-30 IETF LC End Date: 2009-11-18 (oops!) IESG Telechat date: 2009-12-03 Summary: This document is almost ready for publication as a Proposed Standard. I did have one minor question about 13.3 (in my LATE review), but it should not be difficult to resolve, if an AD agrees with my question. I did tag a fair number of nits, but these aren't part of the Gen-ART review, and are simply included as a convenience for anyone else who edits the document. 1. Introduction The GS1 bridge failed to gain wide deployment for any GSS-API mechanism other than The Kerberos V5 GSS-API mechanism [RFC1964] Spencer (nit): s/The Kerberos/The Kerberos/ [RFC4121], and has a number of problems that lead us to desire a new Spencer (nit): s/lead/led/ bridge. Specifically: a) GS1 was not round-trip optimized, b) GS1 did not support channel binding [RFC5056]. These problems and the opportunity to create the next SASL password-based mechanism, SCRAM Spencer (nit): please expand SCRAM on first use. [I-D.ietf-sasl-scram], as a GSS-API mechanism used by SASL applications via GS2, provide the motivation for GS2. In particular, the current consensus of the SASL community appears to be that SASL security layers (i.e., confidentiality and integrity protection of application data after authentication) are too complex and, since SASL applications tend to have an option to run over a Transport Layer Security (TLS) [RFC5246] channel, redundant and best replaced with channel binding. Spencer (nit): it's a LONG way from too complex to redundant in this sentence ;-) suggest moving redundant before the subclause, just for readability. 3.3. Examples The last step translate each decimal value using table 3 in Base32 Spencer (nit): s/translate/translates/? [RFC4648]. Thus the SASL mechanism name for the SPKM-1 GSSAPI mechanism is GS2-DT4PIK22T6A. 8. GSS-API Parameters The mutual_req_flag MUST be set. If channel binding is used then the client MUST check that the corresponding ret_flag is set when the context is fully establish, else authentication MUST fail. Spencer (nit): s/establish/established/ Use or non-use of deleg_req_flag and anon_req_flag is an implementation-specific detail. SASL and GS2 implementors are encouraged to provide programming interfaces by which clients may choose to delegate credentials and by which servers may receive them. SASL and GS2 implementors are encouraged to provide programming interfaces which provide a good mapping of GSS-API naming options. 11. GSS_Inquire_mech_for_SASLname call To allow SASL clients to more efficiently identify which GSS-API mechanism a particular SASL mechanism name refers to we specify a new GSS-API utility function for this purpose. Spencer (nit): whew! hard to parse. Suggest We specify a new GSS-API utility function to allow SASL clients to more efficiently identify the GSS-API mechanism that a particular SASL mechanism name refers to, or something like that? 13.3. Additional Recommendations If the application requires security layers then it MUST prefer the SASL GSSAPI mechanism over GS2-KRB5 or GS2-KRB5-PLUS. Spencer (minor): If prefer the mechanism is the right way to describe this, I apologize, but I don't know what the MUST means in practice - if this needs to be at MUST strength, I'd expect text like MUST use X and MUST NOT use Y or Z, or MUST use X unless the server doesn't support X. 14. GSS-API Mechanisms that negotiate other mechanisms A GSS-API mechanism that negotiate other mechanisms interact badly Spencer (nit): s/negotiate/negotiates/, and probably s/interact/will interact/ ? with the SASL mechanism negotiation. There are two problems. The first is an interoperability problem and the second is a security concern. The problems are described and resolved below. 14.1. The interoperability problem If a client implement GSS-API mechanism X, potentially negotiated through a GSS-API mechanism Y, and the server also implement GSS-API Spencer (nit): s/implement/implements/ mechanism X negotiated through a GSS-API mechanism Z, the authentication negotiation will fail. 14.2. Security problem If a client's policy is to first prefer GSSAPI mechanism X, then non- GSSAPI mechanism Y, then GSSAPI mechanism Z, and if a server supports mechanisms Y and Z but not X, then if the client attempts to negotiate mechanism X by using a GSS-API mechanism that negotiate Spencer (nit): s/negotiate/negotiates/ other mechanisms (such as SPNEGO), it may end up using mechanism Z Spencer (nit): you provide a
[Gen-art] gen-art review: draft-ietf-tcpm-early-rexmt
I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html ). Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-tcpm-early-rexmt-03.txt draft-ietf-tcpm-early-rexmt Reviewer: Joel M. Halpern Review Date: 30-Nov-2009 IETF LC End Date: 8-Dec-2009 IESG Telechat date: N.A Summary: This document is ready for publication as an Experimental RFC ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Gen-ART review of draft-reschke-rfc2731bis-04
Version -04 resolves all my previous comments (and adds no new ones ;-) Thanks, Spencer - Original Message - From: Spencer Dawkins spen...@wonderhamster.org To: draft-reschke-rfc2731...@tools.ietf.org Cc: General Area Review Team gen-art@ietf.org Sent: Wednesday, September 30, 2009 5:43 PM Subject: [Gen-art] Gen-ART review of draft-reschke-rfc2731bis-02 I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please resolve these comments along with any other Last Call comments you may receive. Document: draft-reschke-rfc2731bis-02 Reviewer: Spencer Dawkins Review Date: 2009-10-01 IETF LC End Date: 2009-10-07 IESG Telechat date: (not known) Summary: This document is almost ready for publication as an Informational RFC. I have three comments on this short draft... I wish the IETF community had a clearer understanding of the relationship between Historic and Obsolete than we have, but that's a comment for IESG action, not a comment that can be reasonably made in response to Last Call for this document. Having said that, I THINK this document should be doing both (setting RFC 2731 to Historic AND Obsolete in the RFC Editor database). The title says one, and the text says the other - both should mention both actions, because neither is a superset of the other. I agree with David Harrington's Last Call comment that including the name of the RFC being declared Obsolete/Historic in the title of this draft would be appropriate. I don't expect most members of the IETF community would remember what RFC 2731 was about (sure, you can actually open the document, but most of us probably wouldn't need to do that). Julian pointed out in Last Call discussion that the Dublin Initiative has been maintaining this specification for nearly 10 years. It would probably be helpful if the document provided this timestamp - perhaps something like [RFC2731] defines Encoding Dublin Core Metadata in HTML. Newer specifications published by the Dublin Core Metadata Initiative [1] (DCMI) over the past decade, in particular Expressing Dublin Core metadata using HTML/ ^^^ ^^ XHTML meta and link elements (DC-HTML, http://dublincore.org/documents/dc-html/), have obsoleted this work. Thanks, Spencer ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Gen-ART review of draft-ietf-geopriv-lbyr-requirements-09
Hi, Richard, Yes, -09 does address all the comments I sent on -07. Thanks for your quick response! Spencer - Original Message - From: Richard Barnes rbar...@bbn.com To: Spencer Dawkins spen...@wonderhamster.org Cc: draft-ietf-georpiv-lbyr-requireme...@tools.ietf.org Sent: Monday, November 30, 2009 4:39 PM Subject: Re: Gen-ART review of draft-ietf-geopriv-lbyr-requirements-07 Spencer, -09 is out now: http://tools.ietf.org/rfcdiff?url2=draft-ietf-geopriv-lbyr-requirements-09.txt Does these changes address your concerns? --Richard On Oct 21, 2009, at 8:30 PM, Spencer Dawkins wrote: Hi, Russ, I'm sorry, but I don't see text changes based on my comments in http://tools.ietf.org/wg/geopriv/draft-ietf-geopriv-lbyr-requirements/draft-ietf-geopriv-lbyr-requirements-08-from-07.diff.html . Some of them were nits, which aren't actually part of the Gen-ART review, but my concerns about 2119 language and a couple of sentences that didn't parse probably are worth looking at (just search for pars in my review). Thanks, Spencer Spencer: Draft -08 is on the telechat agenda for tomorrow. Does it resolve your concerns? Russ At 06:47 PM 6/3/2009, Spencer Dawkins wrote: I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-geopriv-lbyr-requirements-07 Reviewer: Spencer Dawkins Review Date: 2009-06-03 IETF LC End Date: 2009-06-09 IESG Telechat date: (not known) Summary: This document is almost ready for publication as an Informational RFC. Comments: Most of my notes below involve text clarity. I did question one 2119 keyword use in Section 4.1, as well. 1. Introduction Location determination, different than location configuration or Spencer (clarity): Is this s/different than/as distinct from/ ? but this sentence didn't parse for me. dereferencing, often includes topics related to manual provisioning processes, automated location calculations based on a variety of measurement techniques, and/or location transformations, (e.g., geo- coding), and is beyond the scope of this document. The issues around location configuration protocols have been documented in a location configuration protocol problem statement and requirements document [I-D.ietf-geopriv-l7-lcp-ps]. There are currently several examples of a location configuration protocols currently proposed, including, DHCP [I-D.ietf-geopriv-dhcp-lbyr-uri-option], LLDP-MED, and HELD Spencer (clarity): got a reference for LLDP-MED here? [I-D.ietf-geopriv-http-location-delivery] protocols. 2. Terminology Location Configuration Protocol: A protocol which is used by a client to acquire either location or a location URI from a Spencer (clarity): I'm guessing here that you mean s/either location/either a location object/ location configuration server, based on information unique to the client. 3.3. Location URI Authorization Location URIs manifest themselves in a few different forms. The different ways that a location URI can be represented is based on local policy, and are depicted in the following four scenarios. 1. No specific information at all: As is typical, a location URI is Spencer (clarity): could this be something more like No location information included in the URI:? used to get location information. However, in this case, the URI representation itself does not need to reveal any specific information at all. Location information is acquired by the dereferencing operation a location URI. 2. No user specific information: By default, a location URI MUST NOT Spencer (clarity): could this be URI does not identify a user:? reveal any information about the Target other than location information. This is true for the URI itself, (or in the document acquired by dereferencing), unless policy explicitly permits otherwise. 3.4. Location URI Construction Depending on local policy, a location URI may be constructed in such a way as to make it difficult to guess. Accordingly, the form of the URI is then constrained by the degree of randomness and uniqueness applied to it. In this case, it may be important to protect the actual location information from inspection by an intermediate node. Spencer (clarity): is this section applicable to all of the scenarios in the previous section, or just to possession authorization model? If not applicable to all, you might point that out here. Construction of a location URI in such a way as to not reveal any domain, user, or device specific information, with the goal of making the location URI appear bland, uninteresting, and generic, may be helpful to some degree in order to keep location information more difficult to detect. Thus,
[Gen-art] Gen-ART telechat review of draft-dusseault-http-patch-16.txt
I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-dusseault-http-patch-16.txt Reviewer: Brian Carpenter Review Date: 2009-12-01 IETF LC End Date: 2009-11-24 IESG Telechat date: 2009-12-03 Summary: Ready, but... Comment: My Last Call comment has been handled, thanks. However, note that during the discussion of that comment, Roy Fielding and Julian Reschke preferred an alternative approach to handling it. I'm not qualified to choose. For details, see http://www.ietf.org/mail-archive/web/ietf/current/msg59517.html___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Gen-ART review of draft-ietf-pkix-rfc3161-update-09
I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html ). Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-pkix-rfc3161-update-09.txt Reviewer: Pete McCann Review Date: 2009-11-30 IETF LC End Date: 2009-11-28 IESG Telechat date: unknown Summary: Ready Major issues: none Minor issues: none Nits/editorial comments: none ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Gen-ART LC Review of draft-ietf-hip-native-api-09
I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-hip-native-api-09 Reviewer: Ben Campbell Review Date: 2009-11-30 IETF LC End Date: 2009-12-03 IESG Telechat date: (if known) Summary: This draft is ready for publication as an experimental RFC. I have a small number of editorial comments that might be worth addressing if there is a new version prior to publication. Major issues: None Minor issues: None Nits/editorial comments: --Section 1, paragraph 3: Please expand ORCHID on first mention. -- Section 1, paragraph 4: Please expand LSI on first mention. -- Section 4.2, first paragraph after figure 3: Am I correct in assuming the EAI_FAMILY error only happens if the ai_family field was set to AF_HIP? That is, it would not make sense for AF_UNSPEC? The paragraph structure makes it looks like it applies to both. -- idnits returns the following, which I include without prejudice: idnits 2.11.15 tmp/draft-ietf-hip-native-api-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see http://trustee.ietf.org/license-info): == The document has an IETF Trust Provisions (12 Sep 2009) Section 6.c(i) Publication Limitation clause. Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt: No issues found here. Checking nits according to http://www.ietf.org/ID-Checklist.html: No issues found here. Miscellaneous warnings: == Line 393 has weird spacing: '... structsoc...' == Line 395 has weird spacing: '... structadd...' == The document seems to lack a disclaimer for pre-RFC5378 work, but was first submitted before 10 November 2008. Should you add the disclaimer? (See the Legal Provisions document at http://trustee.ietf.org/license-info for more information.) -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking references for intended status: Experimental == Outdated reference: A later version (-10) exists of draft-ietf-shim6-multihome-shim-api-09 == Outdated reference: draft-ietf-shim6-proto has been published as RFC 5533 Summary: 0 errors (**), 6 warnings (==), 0 comments (--). Run idnits with the --verbose option for more detailed information about the items above. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] My (Richard) comments to the Gen-ART review of draft-ietf-capwap-base-mib-06
Richard, Comments embedded ... Thanks, --David Hi, All : Please check my comments identified by the [Richard]. To David: Thanks a lot. The important open issues that need to be resolved are tagged with [*]. [*] Intended document status is now Informational. That needs to be changed on the title page, but more importantly, someone (draft shepherd?) should double-check whether the requested IANA allocations are appropriate for an Informational document. If there's a problem here, the IESG should be warned that a process exception may be needed, as I think the allocations are necessary for this draft. [Richard] Margaret or Dan, please confirm it. Dan's working on it. [*] I see lots of editorial problems in the text prior to the MIB definitions, most of which are not called out in this review. I strongly suggest an editorial pass by a native speaker of English prior to IESG Review. Here's an example from Section [Richard] Margaret or Dan, please consider how to handle it. For the text, I can't do better job than a native speaker of English:( Understood - I would hope that one of your co-authors would step up to do this. 5.6 - the use of the word conception is incorrect in this phrase: the protocol of [RFC5416] defines WLAN conception A better word would be creation. [Richard] Hi, David. Whether management instead of creation is better? I think that's ok. Terminology section: - Add a definition of PHY, it's undefined in this document. [Richard] It is a very general conception. I checked the RFC5415, it does not give the definition of PHY. How about: physical layer (PHY) in the place where it first appears? I am ok with adding a definition of PHY if it is a better solution. I think a definition is preferable. For wired Ethernet, the PHY is a specific piece of functionality (can be in a separate chip) that sits between the transceiver and the Ethernet controller. The PHY definition in this draft needs to indicate whether the term covers only this area of functionality vs. covers the entire physical layer including the transceivers and communication medium (e.g., radio transceivers, antennas and wireless signals in this case). - Add a definition of WLAN, while it's defined elsewhere, WLAN is a crucial concept for this draft and hence needs a definition here. [Richard] I am ok. - The definition of station (STA) is sufficiently general to include WTPs. Was that intended? [Richard] I got the definition of station (STA) and WTP from RFC5415. Then I presume this was intended. Section 5.1 should explain the division of management of a WTP between the actual CAPWAP protocol and this MIB. The first bullet creates this confusion, and that bullet is not consistent with the first bullet in 5.4. That lack of consistency should be corrected in addition to providing the explanation. [Richard] I did not get the point. Kindly give more input The first bullet in 5.1 implies that all management of a WTP is via this MIB. OTOH, The first bullet in 5.4 says that the MIB is optional for a WTP. The combination allows unmanaged WTPs - I don't think that was what was intended, rather the basic level of WTP management is in the CAPWAP protocol itself, and the MIB adds additional management functionality. Section 5.4: The ifIndex [RFC2863] is used as a common handler I don't think it's a handler. The ifIndex is actually an index. [Richard] How about use index instead of handler. Ok. [*] The text in Section 5.7 attempts to modify RFC 5415. That's not a good idea for an Informational document. It is ok to say that if the additional requirements are not followed, this MIB will not be useful or usable. [Richard] The WG already made the consensus on it after IETF 75th, and the WG agree to use the following text. The section 4.6.40 [RFC5415] does not clarify that the WTP's Base MAC address MUST be included in the WTP Board Data message element. This is a known errata item and assumed to be fixed in future by the editors of the RFC5415. Make sure that this errata item is filed against RFC 5415 with the RFC Editor. [*] Why is Section 9 (CAPWAP Message Element Extension) in a MIB draft? MIB drafts generally do not make changes to the protocol that they provide management for. This section, and the changes in Section 5.7 ought to be in a separate draft that could be standards track. [Richard] Margaret or Dan, please confirm whether it is allowed to have the Message Element Extension in the MIB drafts. The manageable in the current text To enable CAPWAP protocol timers and variables [RFC5415] manageable through CAPWAP protocol is not very clear. Maybe the word viewable is better. How about we use the text To enable CAPWAP protocol timers and variables [RFC5415] viewable on the AC through CAPWAP protocol ? Since the MIB objects
