Re: Last Call: <draft-farrell-decade-ni-07.txt> (Naming Things with Hashes) to Proposed Standard

Hello Stephen,

On 2012/06/26 20:26, Stephen Farrell wrote:
>
> Hi again Martin,
>
> On 06/26/2012 12:11 PM, "Martin J. Dürst" wrote:
>> So the question is really, what's the use case, and what's just a
>> consequence of that use case. If confirmation of already available
>> resources (e.g. like a fingerprint) is the (main?) use case, and the
>> greater weight on "speakability" just a design consequence, then it
>> makes sense to have two separate things.
>
> Yes, confirmation is the main current use-case for nih as I understand
> it and have said previously.

I sincerely wish you had said this so clearly much, much earlier, or 
even better that it had been in the draft in cristal clear language. We 
could have avoided a lot of useless discussion.

> (Of course the resource might not yet
> be present, so "already available" isn't quite right, but that's a
> nit.)
>
> Have we beaten this to death sufficiently now? I hope so
>
> If you want to suggest a sentence that says that, feel free.

I really don't think it should be my job to explain this. There are 
enough coauthors on the draft who should be in a much better position 

Re: Last Call: <draft-farrell-decade-ni-07.txt> (Naming Things with Hashes) to Proposed Standard

Hi Martin,

On 07/02/2012 12:07 PM, "Martin J. Dürst" wrote:
> Hello Stephen,
> 
> On 2012/06/26 20:26, Stephen Farrell wrote:
>>
>> Hi again Martin,
>>
>> On 06/26/2012 12:11 PM, "Martin J. Dürst" wrote:
>>> So the question is really, what's the use case, and what's just a
>>> consequence of that use case. If confirmation of already available
>>> resources (e.g. like a fingerprint) is the (main?) use case, and the
>>> greater weight on "speakability" just a design consequence, then it
>>> makes sense to have two separate things.
>>
>> Yes, confirmation is the main current use-case for nih as I understand
>> it and have said previously.
> 
> I sincerely wish you had said this so clearly much, much earlier, or
> even better that it had been in the draft in cristal clear language. We
> could have avoided a lot of useless discussion.

I agree this has been harder than it ought have been for some
reason. I guess that just happens sometimes.

> 
>> (Of course the resource might not yet
>> be present, so "already available" isn't quite right, but that's a

Re: [secdir] secdir review of draft-sakane-dhc-dhcpv6-kdc-option

	At first I thought that it might be good to leave section 4.1,
	but now I changed my mind. I think the order of the preference
	might depend on the running environment: some people prefer
	"secured" one, some people prefer DNS...  So I'd like to make
	the order configurable and move section 4.1 to appendix, as a
	hint for implementation.

masahiro

>>>>> On Wed, 27 Jun 2012 15:00:29 -0400, Sam Hartman <hartmans-ietf <at> mit.edu> said:
 > 
>>>>> "t" == t p <daedulus <at> btconnect.com> writes:
t> Just to make public what I have hinted at privately, I think that steps
t> in section 4.1 may be somewhat underspecified.
 > 
t> A related issue is that section 4.1 prefers DNS to DHCP for Kerberos
t> information but the Security Considerations stress the weakness of
t> DHCP and recommend authenticating DHCP.  What if DHCP is secure
t> and DNS is not?  Should DNS still be preferred?
 > 
 > Yes probably.
 > DNS has been and will continue to be the dominant way to discover KDCs.
 > I see this as a specialized DHCP option for certain deployments, not
 > something you'll see in the enterprise for desktops or laptops as an
 > example.
 > I mean some people may deploy it, but I suspect that you won't see it in
 > most situations where DNS works well today.
 > So, basically in all cases, including preconfigured DNS servers, I'd
 > expect DNS to be preferred.

Re: Last Call: <draft-ietf-intarea-ipv4-id-update-05.txt> (Updated Specification of the IPv4 ID Field) to Proposed Standard

Hi,

On 6/20/2012 5:57 PM, Masataka Ohta wrote:
> Though the ID states:
> 
>     This
>     document underscores the point that not only is reassembly (and
>     possibly subsequent fragmentation) required for translation, it can
>     be used to avoid issues with IPv4 ID uniqueness.
> 
> according to RFC2765, which does not need port numbers for
> address mapping:
> 
>     If the IPv6 packet contains a Fragment header the header fields are
>     set as above with the following exceptions:
> 
>           Identification:
>                   Copied from the low-order 16-bits in the
>                   Identification field in the Fragment header.
> 
>           Flags:
>                   The More Fragments flag is copied from the M flag in
>                   the Fragment header.  The Don't Fragments flag is set
>                   to zero allowing this packet to be fragmented by IPv4
>                   routers.
> 
> the translated IPv4 packets are not atomic with 16bit IDs.
> 
> Note that the RFC is referred by NAT646 etc.
> 

Re: [manet] MANET Terminology Update

Dear All

I completed the first version of draft on terminology and submited the
draft yesterday (with getting some techniq problem), but needed to
post to know the community feedback and advise. There are other terms
that was not yet included which will need some advise from you.
Thanking you,

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Abbreviations Used in The submitted Document

   AH   Authentication Header
   DAD  Duplicate Address Detection
   DPD  Duplicate Packet Detection
   DoS  Denial of Service
   ESP  Encapsulating Security Payload
   IP   IPv4 or IPv6
   ICMP Internet Control Message Protocol
   IIB  Interface Information Base
   ETX  Estimated Expected number of Transmission
   FIB  Forwarding Information Base
   LQI  Link Quality Indicator
   L2   Data Link Layer (i.e. 2nd layer in ISO model)
   L3   Internet Layer (i.e. 3rd layer in ISO model)
   LLN  Low power and Lossy Network
   MAC  Mediam Access Control
   MIB  Management Information Base
   MTU  Maximum Transmission Unit
   NBMA Non-Broadcast Multi-Access link
   NHDP Neighborhood Discovery Protocol

RE: Last Call: <draft-farrell-decade-ni-07.txt> (Naming Things with Hashes) to Proposed Standard

Hi Martin,

thanks for the review and advice.

I'd agree that the "confirmation use case" should be highlighted (described better) . Will do that by
adding some text along the lines you mentioned to the intro.

How about this:
----
In addition, we also define a ".well-known" URL equivalent, and a way to include a hash as a segment of an HTTP
URL, as well as a binary format for use in protocols that require more compact names.  Moreover, we define a
human-speakable text form that allows for reading out (and understanding) names so that they can be
transferred over voice connections, which can be used for verifying the presence of an adequate hash or
key information.
----

As to the detailed suggestions, I don't think it is really necessary to rename 'nih' to 'fingerprint' and to
get rid of "Human-speakable" as a description for it. In the end, those URIs are essentially
"human-speakable" -- so that they can be used for confirming the presence/absence of resources.

I don’t like 'fingerprint' as a scheme identifier, because a) those URIs, unlike PK fingerprints,
actually contain the complete hash information and b) because it does not convey the relationship to
'ni'. I think it's fine to stick to 'nih' here.

I agree that the nid separators can be useful. Would be OK for me to still add them.

Thanks,
Dirk

Gen-ART review of draft-ietf-behave-lsn-requirements-07

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-behave-lsn-requirements-07
Reviewer: Alexey Melnikov
Review Date: 3-July-2012
IETF LC End Date: 10-July-2012
IESG Telechat date: Pending

Summary: The document is ready for publication as a BCP.

Major Issues: None

Minor Issues: None

Nits/editorial comments:

I found it is to be odd to have a requirements document as a BCP, but I 
am sure
you can sort the right status out with IESG.

I found the justification for REQ-6 hard to read/understand. Why does 
access to
servers being on the internal network need to go through CGN at all?

REQ-10:

Re: Gen-ART review of draft-ietf-behave-lsn-requirements-07

On Jul 3, 2012, at 14:24, Alexey Melnikov wrote:
> I found it is to be odd to have a requirements document as a BCP, but I am sure
> you can sort the right status out with IESG.

+1

I fail to see why Informational wouldn't be the better status.

Lars

Gen-ART LC Review of draft-ietf-oauth-urn-sub-ns-05

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-oauth-urn-sub-ns-05
Reviewer: Ben Campbell
Review Date: 2012-07-03
IETF LC End Date: 2012-07-11

Summary: Ready for publication as a proposed standard

Major issues: None

Minor issues: None

Nits/editorial comments:

-- section 2:

The RFC 2119 boilerplate is present, but I don't notice any 2119 normative language.

-- section 4, first sentence: "None not already inherent to using URNs."

Sentence Fragment.

-- section 5.1, last bullet, "... values subordinate to urn:ietf:params:oauth are of the from ..."

RE: IETF Nominations Committee Chair - 2012 - 2013