e same type
>> - equivalent objects with the members in different orders.
>> These could also show off escape sequences and maximally compact formats
>> (using the equivalent object example to show that the white space is
>> irrelevant).
For a new format, additional exampl
order the entries come in.
That is a reasonable assumption, but it turns out there are many different
reasonable assumptions.
However, I can't tell if you consider this a "minor issue" or you really want
to force the WG to come up with a consensus definition for "unorder
/value pairs,
including duplicates.
--Paul Hoffman
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
s is so important to
you, given that the document already has a paragraph about the interoperability
issues? If we're completely missing something, we should work on it; but I'm
hearing very mixed messages from you about the topic.
--Paul Hoffman
ing RFC 4627 to standards track with no warning about the sloppiness.
--Paul Hoffman
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
e is true and fits
into the "tell folks about interoperability issues" category without saying
what developers should/SHOULD do.
Jari, would that meet your goal for the DISCUSS?
--Paul Hoffman
___
Gen-art mailing list
Gen-art@ietf.org
h
Thanks for the review!
--Paul Hoffman
On Apr 3, 2014, at 4:05 PM, Ben Campbell wrote:
> 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 reso
Comment-on-comments below. I now have one new action item.
--Paul Hoffman
On Apr 7, 2014, at 11:37 AM, Ben Campbell wrote:
> Hi, thanks for the quick response. Comments inline; sections that do not seem
> to need further comment are deleted, and marked with "[...]"
>
On Apr 7, 2014, at 1:39 PM, Ben Campbell wrote:
> On Apr 7, 2014, at 2:42 PM, Paul Hoffman wrote:
>
>> Comment-on-comments below. I now have one new action item.
>>
>> --Paul Hoffman
>>
>>>>
>>>>> --2.2:
>>>>>
>
an appear. (for example,
> marking as deprecated in the content model listing for
> ). On the other hand, that may be a pain to get right.
This has been suggested many times. We'll see if we can add this to the
tooling, but it might be very difficult to do
that would indeed be clearer.
> Section 2 JSON Text Sequence Format:
>
> I suggest adding this sentence as a separate paragraph at the end of this
> section (i.e., just before Section 2.1):
>
> JSON text sequences MUST use UTF-8 encoding; other encodings of JSON
> (i.e.,
ix A Q&A for OPS-Dir review ---
RFC 5706 Appendix A is generally inapplicable to this draft, as this
draft
is primarily a set of definitions that have no operational impact on
their
own, let alone a need for management protocol support.
Clarity of terms improves the foundation for operation of the
Internet,
and in that regard, this is a generally worthy document that should be
published.
We sure hope so.
Thanks again for the review! You will see the above changes in the next
draft.
--Paul Hoffman
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
are undefined and should not
be
used, with use of the more specific terms in RFC 4033 being
preferable?
If so, that's not clear.
We are not making any judgement on RFCs that used those undefined terms.
What happened happened. It is useful to the readers of this document to
know that ther
met by Paul's
"this was already discussed". We haven't see any other messages since
the publication that would require a -16, but let's see what the IESG
discussion teases out.
--Paul Hoffman
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
defined in the diagrams in RFC 1035.
>
> SB> With or without the UDP header?
Without. RFC 1035 says nothing about the UDP header as part of the wire format.
>
> ==
>
> Minor issues:
>
> Abstract
>
> This document describes how to make DNS queries ove
t; tell them.
We did that in an earlier draft and was told by the WG to take it out because
it was confusing.
>>> SB> 4.2.2 does not seem to describe a format, unless you are implicitly
>>> SB> saying that 4.2.1 does not have a length 4.2.2 does
>>
>> That is e
ment (if such a thing
comes into existence) could rip out this section and refer to it.
The main thing here is that this document doesn't change an existing definition
of "referrals". We just kinda realized that we had to get it written down the
first time.
--Paul Hoffman
__
Thanks, Francis! I have made these changes in the -07 draft that will
come out after the IETF last call.
--Paul Hoffman, Director
--VPN Consortium
___
Gen-art mailing list
Gen-art@ietf.org
https://www1.ietf.org/mailman/listinfo/gen-art
s to whether this section should mention
RFC 3168's changes to this area of RFC 2401, as it is not
necessary to the discussion.
We want to keep this document aligned with RFC 4301, for better or worse.
--Paul Hoffman, Director
--VPN Consortium
__
;. Because
tools.ietf.org makes reading Internet Draft diffs so easy, there is
really no good reason to not have the input to the RFC Editor be a
known-clean document.
--Paul Hoffman, Director
--VPN Consortium
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
d work; it is always fun to see things brought up by
GenArt that are missed by everyone else...
--Paul Hoffman, Director
--VPN Consortium
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
ational RFC, which is what the WG
agreed to.
>Major issues: 0.
>Minor issues: 0.
>Nits/editorial comments: 0.
Whee!
--Paul Hoffman, Director
--VPN Consortium
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
At 11:17 AM -0500 10/16/09, Vijay K. Gurbani wrote:
>Paul Hoffman wrote:
>>I'm not sure where you see "UNKNOWN": when I look at that URL on the
>>data tracker, it says it is intended as an Informational RFC, which
>>is what the WG agreed to.
>
>Paul:
here.
Does that clear up your issue, or are you saying that
draft-ietf-ipsecme-ikev2bis should reverse the old policy and explicitly pull
in the text from RFC 4307 and RFC 4308 into the new document?
--Paul Hoffman, Director
--VPN Consortium
___
lists in the IETF: it is
done on some of them. The IETF still has no consistent guidance on this, and
there are plausibly successful examples of different styles of RFCs.
>So easy enough to solve.
I know of no survivors of newtrk (@#$%) who would agree with that statement.
--Paul Hoffman, Director
--VPN Consortium
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
uot;.
Agree.
>If you want to cite the RFCs involved, IP over FC is RFC 4338 and FC over IP
>is RFC 3821.
I don't those help here.
>idnits 2.12.04 found some minor nits:
>
> ** There are 4 instances of too long lines in the document, the longest one
> being
>+1 to all that.
Putting an explanation such as the above in the document will help future IETFs
to decide when to make this a MUST NOT. It might also help the CA/Browser Forum
and specific CAs see that they should stop doing this ASAP, and maybe even
convince a particular legacy OS vendor to support TLS SNI.
--Paul Hoffman, Director
--VPN Consortium
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
ks for the review. Everything on your list seemed fine, and will
appear in the next draft.
--Paul Hoffman
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
rements that
> would have to be met in that proposal? This may or may not be desired as
> this section usually refers to the security of a protocol, etc.
I don't think this is desired because those will be defined somewhere else,
probably not in the statement o
ade in Unicode 6.0".
> I think that it relates also to the issue of whether this draft updates RFC
> 5892.
And here too.
--Paul Hoffman
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
y the derived property value differs
depending on whether the property definitions used are from Unicode
5.2 or 6.0.
We intended that as "non-backwards-compatible"; we can change the wording to
make that explicit.
--Paul Hoffman
___
Gen-a
gistry update, but they really
aren't: the update was already specified in 5892. We can change the IANA
considerations to reflect that:
IANA will update the derived property value registry according to
RFC 5892 and property values as defined in The Unicode Standard
ry itself doesn't look like it tried, it may be implausible to think that
IANA would just start to do so in some future. To me, "a registry" means a
single registry.
--Paul Hoffman
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
is trying to achieve?
RFC 4308, "Cryptographic Suites for IPsec", is unusual, and is an exception to
that "rarely". A small but significant number of IPsec VPN vendors have
followed it.
--Paul Hoffman
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
n key removes the redaction from all reports that used that key.
Agree.
> As part of this, guidance should be provided on when and how to change the
> redaction key in order to limit the effects of loss of secrecy for a single
> redaction key.
Disagree, given that we have absolutely no id
On Feb 13, 2012, at 3:08 PM, Russ Housley wrote:
> I have not seen a updated document to resolve this concern.
One was not requested. If you need it in order to prevent a DISCUSS, by all
means let us know and we'll pump one out.
--Paul
On Feb 13, 2012, at 3:08 PM, Russ Housley wrote:
> I have not seen a updated document to resolve this concern.
You have now. :-)
--Paul Hoffman
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
s well. Because 7320 has been used as a means of saying "you
can't do what you want" to some protocol proposals, I definitely expect
folks to look at the history if that happens in the future with 7320bis.
--Paul Hoffman
___
Gen-art
likely. I would be happy to be wrong here.
--Paul Hoffman
smime.p7s
Description: S/MIME cryptographic signature
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
quite unclear, and
needs to be clarified before the IESG considers it.
--Paul Hoffman
smime.p7s
Description: S/MIME cryptographic signature
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
Thanks; fixed.
> b) Lack of an example .alt TLD as indicated in the Artart LC Review. I wonder
> if this is due to maybe there will be none.
There is one example mentioned: "example.alt". We didn't want to list more
because doing so would possibly indicate some reservati
defines them,
but that is not where they were first used.)
> Nits
> - S2, right above "Private DNS:", please expand PTI on first use.
Will do.
> - S3, in the definition of QNAME,
> s/this creates kind of confusion/this creates confusion/
> ("kind of" is okay for c
tely new definition that has not been vetted by the WG is inappropriate
for an erratum.
> On the other hand, spending a week or two repeating a cycle to get an
> important term in the current document seems like a better solution.
If the
; probably what was meant was probably 'Updated the RFC Considerations Section'.
Good catch; fixed.
--Paul Hoffman
___
Gen-art mailing list -- gen-art@ietf.org
To unsubscribe send an email to gen-art-le...@ietf.org
44 matches
Mail list logo
