Ertekin, Emre [USA] wrote:
Hi Elwyn,
Thank you for taking the time to review and comment on our draft; sorry for our
late reply. Please see our responses below.
Summary: Almost ready. There should probably be a formal ASN.1
description
of the additional fields in the 'Processing' component of the SPD as
well as
the informal textual description to match RFC 4301. I believe this
document
should be specified as updatinbg RFC 4301 (IPsec).
Major issues: None.
Minor issues:
Status: Presumably this document should be classified as updating RFC
4301
since it modifies the SPD etc.
Although we are modifying the SPD, I would consider these as (optional)
extensions rather than updates to the base IPsec RFC. Further, we are not
changing any of the text of RFC 4301. Therefore, we would prefer to leave the
draft as-is.
Please let us know if this is ok with you.
The term 'optional' seems inappropriate. The draft uses 'must' (should
thus be 'MUST'?) in s2.1 when describing things that need to be added
to the SPD if ROHC is in use. Be that as it may, this is indeed an
extension. From the point of view of implementors, having an explicit
pointer to the RFC which this draft will become from RFC 4301 would help
people find things they might need to implement. Also if one was making
RFC 4301bis it would probably be good to merge in this work. It would
probably be better if one had an 'extends' category rather than just
'updates' but we don't. If your AD is happy that this is not an
'updates' then I'll live with it.
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:
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.
Regards,
Elwyn
BR,
Emre
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
